What Does a Typical ./Configure Do in Linux

What does a typical ./configure do in Linux?

Typically the configure script when run will:

• Check some details about the machine
  on which the software is going to be
  installed. This script checks for
  lots of dependencies on your system.
  For the particular software to work
  properly, it may be requiring a lot
  of things to be existing on your
  machine already. If any of the major requirements are missing on your system, the configure script would exit and you cannot proceed with the installation, until you get those required things.

• Create the Makefile to be used in the next step.

How do I create a configure script?

To create the standard "configure" script you need GNU autoconf.
You may need GNU automake and libtool too.

There are tons of documentation and howtos.
Google for something like "autoconf automake howto".
The good documentation is in the official manual pages:

• Autoconf: http://www.gnu.org/software/autoconf/
• Automake: http://www.gnu.org/software/automake/automake.html
• Libtool: http://www.gnu.org/software/libtool/libtool.html

Autoconf will create your configure script starting from the "configure.ac" file.
The "Makefile.am" file will instruct automake on how to create your makefile by the configure string. Libtool is needed to simplify libraries handling around your code.

You can start creating a configure.ac file by hand or you may use the "autoscan" helper that may help you to create something semi-automatic for you.

Then, when you are ready, this one will do the magic:

autoreconf -i

What does the colon char do in this GNU configure script?

The colon built-in in this case does what it always does: nothing, successfully.

You can always write a command after the then keyword, like this:

if [ some test ]; then do one thing
    do another thing
fi

In this particular case the author is using : as the first command, possibly because of the typographic effect.

Another reason to use : after the then keyword could be ensuring correctness in case lines are removed or commented in the if statement. For example this would be illegal syntax if the colon was removed:

if [ some test ]; then :
    # do one thing     ## Disabled due to bug #12992
fi

What are makefiles, 'make install', etc.?

make is part of the build system commonly used in Unix-type systems - binutils.

It looks at make files which hold configuration information and build targets.

Specifically -

• ./configure - this is a script that sets up the environment for the build
• make - calls make with the default build target. Normally builds the application.
• make install - calls make with the install build target. Normally installs the application.

What is the job of autogen.sh when building a c++ package on Linux

The steps:

1. The autogen.sh script generates the configure script (from configure.ac, using autoconf) and any files it needs (like creating Makefile.in from Makefile.am using automake). This requires autotools to be installed on your system, and it must be run when checking out the project from source control (if configure isn’t checked in). People who download source tarballs can usually skip this step, because output of this step is included in source tarballs.

   Note This is usually equivalent to autoreconf --install. If there is not autogen.sh file, then just run autoreconf --install instead. If you have inherited a project with an autogen.sh, consider deleting it if you can use autoreconf --install.

2. The configure script generates Makefile and other files needed to build. Typically Makefile.in is used as a template to generate Makefile (and config.h.in to generate config.h). This process happens using only standard tools installed on your system, like sed and awk, and doesn't require autotools to be installed.

3. The make command builds the software.

4. The make install command installs it.

These are broken into different steps because they are often run at different times. The autogen.sh step is traditionally run by people who are developing the software, since they are expected to install autoconf on their systems and they make changes to configure.ac. End-users are not expected to have autotools installed.

These expectations have been changed a bit now that end-users are more likely to check a project out of source control instead of downloading source releases.

gvim with huge features

On Ubuntu and every other Debian-based distros, you only need this command to install a proper Vim:

$ sudo apt-get install vim-gnome

Why use build tools like Autotools when we can just write our own makefiles?

You are talking about two separate but intertwined things here:

• Autotools
• GNU coding standards

Within Autotools, you have several projects:

• Autoconf
• Automake
• Libtool

Let's look at each one individually.

Autoconf

Autoconf easily scans an existing tree to find its dependencies and create a configure script that will run under almost any kind of shell. The configure script allows the user to control the build behavior (i.e. --with-foo, --without-foo, --prefix, --sysconfdir, etc..) as well as doing checks to ensure that the system can compile the program.

Configure generates a config.h file (from a template) which programs can include to work around portability issues. For example, if HAVE_LIBPTHREAD is not defined, use forks instead.

I personally use Autoconf on many projects. It usually takes people some time to get used to m4. However, it does save time.

You can have makefiles inherit some of the values that configure finds without using automake.

Automake

By providing a short template that describes what programs will be built and what objects need to be linked to build them, Makefiles that adhere to GNU coding standards can automatically be created. This includes dependency handling and all of the required GNU targets.

Some people find this easier. I prefer to write my own makefiles.

Libtool

Libtool is a very cool tool for simplifying the building and installation of shared libraries on any Unix-like system. Sometimes I use it; other times (especially when just building static link objects) I do it by hand.

There are other options too, see StackOverflow question Alternatives to Autoconf and Autotools?.

Build automation & GNU coding standards

In short, you really should use some kind of portable build configuration system if you release your code to the masses. What you use is up to you. GNU software is known to build and run on almost anything. However, you might not need to adhere to such (and sometimes extremely pedantic) standards.

If anything, I'd recommend giving Autoconf a try if you're writing software for POSIX systems. Just because Autotools produce part of a build environment that's compatible with GNU standards doesn't mean you have to follow those standards (many don't!) :) There are plenty of other options, too.

Edit

Don't fear m4 :) There is always the Autoconf macro archive. Plenty of examples, or drop in checks. Write your own or use what's tested. Autoconf is far too often confused with Automake. They are two separate things.

Confused about configure script and Makefile.in

In order to really understand the autotools utilities you have to remember where they come from: they come from an open source world where there are (a) developers who are working from a source code repository (CVS, Git, etc.) and creating a tar file or similar containing source code and putting that tar file up on a download site, and (b) end-users who are getting the source code tar file, compiling that source code on their system and using the resulting binary. Obviously the folks in group (a) also compile the code and use the resulting binary, but the folks in group (b) don't have or need, often, all the tools for development that the folks in group (a) need.

So the use of the tools is geared towards this split, where the people in group (b) don't have access to autoconf, automake, etc.

When using autoconf, people generally check in the configure.ac file (input to autoconf) into source control but do not check in the output of autoconf, the configure script (some projects do check in the configure script of course: it's up to you).

When using automake, people generally check in the Makefile.am file (input to automake) but do not check in the output of automake: Makefile.in.

The configure script basically looks at your system for various optional elements that the package may or may not need, where they can be found, etc. Once it finds this information, it can use it to convert various XXX.in files (typically, but not solely, Makefile.in) into XXX files (for example, Makefile).

So the steps generally go like this: write configure.ac and Makefile.am and check them in. To build the project from source code control checkout, run autoconf to generate configure from configure.ac. Run automake to generate Makefile.in from Makefile.am. Run configure to generate Makefile from Makefile.in. Run make to build the product.

When you want to release the source code (if you're developing an open source product that makes source code releases) you run autoconf and automake, then bundle up the source code with the configure and Makefile.in files, so that people building your source code release just need make and a compiler and don't need any autotools.

Because the order of running autoconf and automake (and libtool if you use it) can be tricky there are scripts like autogen.sh and autoreconf, etc. which are checked into source control to be used by developers building from source control, but these are not needed/used by people building from the source code release tar file etc.

Autoconf and automake are often used together but you can use autoconf without automake, if you want to write your own Makefile.in.

---

Related Topics