I'm currently trying to set up a package to be installed with autotools.
In most, if not all, major software packages, configure --help lists a large number of options like ./configure --ENABLE-FLOAT, etc. I was wondering where I can define these options.
Thanks,
Sam
Use AC_ARG_ENABLE and AC_ARG_WITH in your configure.ac file.
Related
Bear with me, this one's not very easy to explain...
I'm trying to configure, make and make install Xfce into my buildroot build directory. When configuring I'm using
--prefix=/home/me/somefolder/mybuild/output/target
so that it builds to the right folder, however when it's compressed and run I get errors from various config files where it's looking for files in
/home/me/somefolder/mybuild/output/target
(which of course doesn't exist.)
How do I set what folder to build into, yet set a different root directory for the config files to use?
Do configure --help and see what other options are available.
It is very common to provide different options to override different locations. By standard, --prefix overrides all of them, so you need to override config location after specifying the prefix. This course of actions usually works for every automake-based project.
The worse case scenario is when you need to modify the configure script, or even worse, generated makefiles and config.h headers. But yeah, for Xfce you can try something like this:
./configure --prefix=/home/me/somefolder/mybuild/output/target --sysconfdir=/etc
I believe that should do it.
In my situation, --prefix= failed to update the path correctly under some warnings or failures. please see the below link for the answer.
https://stackoverflow.com/a/50208379/1283198
I have seen that while installing new software in Linux, I always have to use first configure it.
But sometimes we need to pass various options like I did today to install lxml:
./configure --with-python=/opt/python27/bin/python
--prefix=/usr/local
--with-libxml-prefix=/usr/local
--with-libxml-include-prefix=/usr/local/include
--with-libxml-libs-prefix=/usr/local/lib
Now I want to know that how will the person know that what type of paramaters like --with-python can be used?
I mean:
Are those parameters same across all software packages or they vary software to software?
I even tried to read documentation as well, but no one mentions those parameters.
./configure --help
That will show you all options for that particular configure script.
Some are the same across all configure scripts produced by Autoconf (which is most of them, but not all); for instance --prefix is basically universal. Others are peculiar to the particular configure script.
./configure --help is always helpful. But I would say more about that in some packages not only is there a configure script in the top source directory but also the possible subdirectories. So, for knowing all possible parameters which can be passed to the configure script in the top source directory you should also have a look at the configure scripts in each possible subdirectory.
For example, in the top source directory of binutils-2.34 tarball there are --with-sysroot and --with-lib-path parameters with configure script. If you type ./configure --help under the top source directory, there are no document items for both of them because they are documented in the configure script under the subdirectory ld/. So you should type ./ld/configure --help.
I know about configure --help but the information provided is "light". The following GNU resources contain useful additional information:
Installation directory variables
Release process
Autoconf script (./configure) often is created so it can build software with different set of components. For example, while building lynx web browser i can use ./configure --with-openssl to trigger corresponding #ifdef in app source code and make it with open SSL support.
If i have a third-party ./configure.sh file, is it any way to get a list of supported --with statements from it?
Yes, if the configure script was built by autoconf, you can just type ./configure --help to see what --with and --enable options are available.
Is there an easy procedure to build an RPM.If so Please explain or provide the link.........
My requirement is very simple ..
I have two other RPMs which should be combined into one single RPM....
Please explain the process....
Thanks in advance..........
Building an RPM itself is rather easy, you just need to run
rpmbuild -ba <mypackage.spec>
The more complex task is creating the .spec file, which controls how the rpm itself is built. A good explanation is the book Maximum RPM, which is available on the rpm homepage. Creating a .spec file is handled here. From my own experience building a .spec file is something that's not easy -- but not too complicated either unless you want to make special things. The standard ./configure && make && make install is usually not too complicated.
Not sure what the problem is; if you've already got two RPMs, why do you need to make them into 1 rpm? Why not just use a shell script to install them both at the same time?
The RPM command will take multiple arguments, so for example:
rpm -ivh one.rpm two.rpm three.rpm
Will install one, followed by two, followed by three.
Otherwise, from what I know, you're going to have to build the packages first, and then build them into an RPM, at which point you will have a custom RPM that will have to be manually updated every time one of the component packages changes. Yuck.
Basic guide for RPM creation is available at:
http://fedoraproject.org/wiki/How_to_create_an_RPM_package
A very good and complete guide for RPM creation (by Fedora community) is available at link: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/
It is is wonderful.
BTW, for straight answer of your question, you might want to add two packages as a subpackage of another package. For that there are some specific entries in RPM spec file.
You need to create only one SPEC file for all three packages
I've stumbled on a make file "Makefile.am" and I tried to use "make -f Makefile.am" on it to no avail. What am I doing wrong?
It's an automake script/makefile. You can learn everything about automake, autoconf, libtool and such through the called autobook.
Basically, the steps would be to run automake, then autoconf, then configure, then make to build the software you have. These steps are neccessary to build the configure script, that automatically search for needed libraries and such on your system.
The process is not easy, unless your software also includes an already generated "configure" file. If so, the only thing you have to do (mostly) is to just run ./configure, then make, then make install to install the software to a default location. If you want to change configure options, you can also look at ./configure --help.
You stumbled upon an automake file, which is used to create a Makefile from the source, in this case Makefile.am.
From http://developer.gnome.org/doc/GGAD/z70.html, they explain it as:
automake processes Makefile.am to produce a standards-compliant Makefile.in. automake does a lot of work for you: it keeps up with dependencies between source files, for example. It creates all the standard targets, such as install and clean. It also creates more complex targets: simply typing make dist creates a standard .tar.gz file if your Makefile.am is correct.
Basically, you should run 'automake' to make the Makefile, and you will probably run into the same situation with the configure script with 'autoconf'.
Automake: http://www.gnu.org/software/automake/
Wikipedia article on automake: http://en.wikipedia.org/wiki/Automake
If you are trying to compile a 3rd party application from source, there is usually a 'configure' script located at the top of the source tree. If you run ./configure --help from that location, you'll get a list of options you can set. Usually, --prefix is the most common to use.
After running the script, you'll get standard Makefile's generated from the automake files. From there, you can just execute make normally.
Standard build steps for linux packages are:
./configure
make
make install
see "man automake" or google for autotools. likely you'll want to run something like autogen.sh first.