17. Frequent Autoconf Questions, with answers

Several questions about Autoconf come up occasionally. Here some of them are addressed.

17.1 Distributing configure Scripts		Distributing configure scripts
17.2 Why Require GNU M4?		Why not use the standard M4?
17.3 How Can I Bootstrap?		Autoconf and GNU M4 require each other?
17.4 Why Not Imake?		Why GNU uses configure instead of Imake
17.5 How Do I #define Installation Directories?		Passing datadir to program
17.6 What is `autom4te.cache'?		What is it? Can I remove it?

17.1 Distributing configure Scripts

What are the restrictions on distributing configure scripts that Autoconf generates? How does that affect my programs that use them?

There are no restrictions on how the configuration scripts that Autoconf produces may be distributed or used. In Autoconf version 1, they were covered by the GNU General Public License. We still encourage software authors to distribute their work under terms like those of the GPL, but doing so is not required to use Autoconf.

Of the other files that might be used with configure, `config.h.in' is under whatever copyright you use for your `configure.ac'. `config.sub' and `config.guess' have an exception to the GPL when they are used with an Autoconf-generated configure script, which permits you to distribute them under the same terms as the rest of your package. `install-sh' is from the X Consortium and is not copyrighted.

17.2 Why Require GNU M4?

Why does Autoconf require GNU M4?

Many M4 implementations have hard-coded limitations on the size and number of macros that Autoconf exceeds. They also lack several builtin macros that it would be difficult to get along without in a sophisticated application like Autoconf, including:

m4_builtin m4_indir m4_bpatsubst __file__ __line__

Autoconf requires version 1.4 or above of GNU M4 because it uses frozen state files.

Since only software maintainers need to use Autoconf, and since GNU M4 is simple to configure and install, it seems reasonable to require GNU M4 to be installed also. Many maintainers of GNU and other free software already have most of the GNU utilities installed, since they prefer them.

17.3 How Can I Bootstrap?

If Autoconf requires GNU M4 and GNU M4 has an Autoconf configure script, how do I bootstrap? It seems like a chicken and egg problem!

This is a misunderstanding. Although GNU M4 does come with a configure script produced by Autoconf, Autoconf is not required in order to run the script and install GNU M4. Autoconf is only required if you want to change the M4 configure script, which few people have to do (mainly its maintainer).

17.4 Why Not Imake?

Why not use Imake instead of configure scripts?

Several people have written addressing this question, so I include adaptations of their explanations here.

The following answer is based on one written by Richard Pixley:

Autoconf generated scripts frequently work on machines that it has never been set up to handle before. That is, it does a good job of inferring a configuration for a new system. Imake cannot do this.

Imake uses a common database of host specific data. For X11, this makes sense because the distribution is made as a collection of tools, by one central authority who has control over the database.

GNU tools are not released this way. Each GNU tool has a maintainer; these maintainers are scattered across the world. Using a common database would be a maintenance nightmare. Autoconf may appear to be this kind of database, but in fact it is not. Instead of listing host dependencies, it lists program requirements.

If you view the GNU suite as a collection of native tools, then the problems are similar. But the GNU development tools can be configured as cross tools in almost any host+target permutation. All of these configurations can be installed concurrently. They can even be configured to share host independent files across hosts. Imake doesn't address these issues.

Imake templates are a form of standardization. The GNU coding standards address the same issues without necessarily imposing the same restrictions.

Here is some further explanation, written by Per Bothner:

One of the advantages of Imake is that it easy to generate large Makefiles using cpp's `#include' and macro mechanisms. However, cpp is not programmable: it has limited conditional facilities, and no looping. And cpp cannot inspect its environment.

All of these problems are solved by using sh instead of cpp. The shell is fully programmable, has macro substitution, can execute (or source) other shell scripts, and can inspect its environment.

Paul Eggert elaborates more:

With Autoconf, installers need not assume that Imake itself is already installed and working well. This may not seem like much of an advantage to people who are accustomed to Imake. But on many hosts Imake is not installed or the default installation is not working well, and requiring Imake to install a package hinders the acceptance of that package on those hosts. For example, the Imake template and configuration files might not be installed properly on a host, or the Imake build procedure might wrongly assume that all source files are in one big directory tree, or the Imake configuration might assume one compiler whereas the package or the installer needs to use another, or there might be a version mismatch between the Imake expected by the package and the Imake supported by the host. These problems are much rarer with Autoconf, where each package comes with its own independent configuration processor.

Also, Imake often suffers from unexpected interactions between make and the installer's C preprocessor. The fundamental problem here is that the C preprocessor was designed to preprocess C programs, not `Makefile's. This is much less of a problem with Autoconf, which uses the general-purpose preprocessor M4, and where the package's author (rather than the installer) does the preprocessing in a standard way.

Finally, Mark Eichin notes:

Imake isn't all that extensible, either. In order to add new features to Imake, you need to provide your own project template, and duplicate most of the features of the existing one. This means that for a sophisticated project, using the vendor-provided Imake templates fails to provide any leverage--since they don't cover anything that your own project needs (unless it is an X11 program).

On the other side, though:

The one advantage that Imake has over configure: `Imakefile's tend to be much shorter (likewise, less redundant) than `Makefile.in's. There is a fix to this, however--at least for the Kerberos V5 tree, we've modified things to call in common `post.in' and `pre.in' `Makefile' fragments for the entire tree. This means that a lot of common things don't have to be duplicated, even though they normally are in configure setups.

17.5 How Do I #define Installation Directories?

My program needs library files, installed in datadir and similar. If I use   AC_DEFINE_UNQUOTED([DATADIR], [$datadir], [Define to the read-only architecture-independent data directory.]) I get   #define DATADIR "${prefix}/share"

As already explained, this behavior is on purpose, mandated by the GNU Coding Standards, see 4.7.2 Installation Directory Variables. There are several means to achieve a similar goal:

• Do not use AC_DEFINE but use your `Makefile' to pass the actual value of datadir via compilation flags, see 4.7.2 Installation Directory Variables, for the details.

• This solution can be simplified when compiling a program: you may either extend the CPPFLAGS:

  CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@

  or create a dedicated header file:

  DISTCLEANFILES = datadir.h datadir.h: Makefile echo '#define DATADIR "$(datadir)"' >$@

• Use AC_DEFINE but have configure compute the literal value of datadir and others. Many people have wrapped macros to automate this task. For instance, the macro AC_DEFINE_DIR from the Autoconf Macro Archive.

  This solution does not conform to the GNU Coding Standards.

• Note that all the previous solutions hard wire the absolute path to these directories in the executables, which is not a good property. You may try to compute the paths relatively to prefix, and try to find prefix at runtime, this way your package is relocatable. Some macros are already available to address this issue: see adl_COMPUTE_RELATIVE_PATHS and adl_COMPUTE_STANDARD_RELATIVE_PATHS on the Autoconf Macro Archive.

17.6 What is `autom4te.cache'?

What is this directory `autom4te.cache'? Can I safely remove it?

In the GNU Build System, `configure.ac' plays a central role and is read by many tools: autoconf to create `configure', autoheader to create `config.h.in', automake to create `Makefile.in', autoscan to check the completeness of `configure.ac', autoreconf to check the GNU Build System components that are used. To "read `configure.ac'" actually means to compile it with M4, which can be a very long process for complex `configure.ac'.

This is why all these tools, instead of running directly M4, invoke autom4te (see section 8.2.1 Invoking autom4te) which, while answering to a specific demand, stores additional information in `autom4te.cache' for future runs. For instance, if you run autoconf, behind the scenes, autom4te will also store information for the other tools, so that when you invoke autoheader or automake etc., re-processing `configure.ac' is not needed. The speed up is frequently of 30, and is increasing with the size of `configure.ac'.

But it is and remains being simply a cache: you can safely remove it.

Can I permanently get rid of it?

The creation of this cache can be disabled from `~/.autom4te.cfg', see 8.2.2 Customizing autom4te, for more details. You should be aware that disabling the cache slows down the Autoconf test suite by 40%. The more GNU Build System components are used, the more the cache is useful; for instance running `autoreconf -f' on the Coreutils is twice slower without the cache although `--force' implies that the cache is not fully exploited, and eight times slower than without `--force'.