autoconf: Why Not Imake
1
1 20.4 Why Not Imake?
1 ===================
1
1 Why not use Imake instead of `configure' scripts?
1
1 Several people have written addressing this question, so adaptations
1 of their explanations are included here.
1
1 The following answer is based on one written by Richard Pixley:
1
1 Autoconf generated scripts frequently work on machines that it has
1 never been set up to handle before. That is, it does a good job of
1 inferring a configuration for a new system. Imake cannot do this.
1
1 Imake uses a common database of host specific data. For X11, this
1 makes sense because the distribution is made as a collection of
1 tools, by one central authority who has control over the database.
1
1 GNU tools are not released this way. Each GNU tool has a
1 maintainer; these maintainers are scattered across the world.
1 Using a common database would be a maintenance nightmare.
1 Autoconf may appear to be this kind of database, but in fact it is
1 not. Instead of listing host dependencies, it lists program
1 requirements.
1
1 If you view the GNU suite as a collection of native tools, then the
1 problems are similar. But the GNU development tools can be
1 configured as cross tools in almost any host+target permutation.
1 All of these configurations can be installed concurrently. They
1 can even be configured to share host independent files across
1 hosts. Imake doesn't address these issues.
1
1 Imake templates are a form of standardization. The GNU coding
1 standards address the same issues without necessarily imposing the
1 same restrictions.
1
1 Here is some further explanation, written by Per Bothner:
1
1 One of the advantages of Imake is that it is easy to generate large
1 makefiles using the `#include' and macro mechanisms of `cpp'.
1 However, `cpp' is not programmable: it has limited conditional
1 facilities, and no looping. And `cpp' cannot inspect its
1 environment.
1
1 All of these problems are solved by using `sh' instead of `cpp'.
1 The shell is fully programmable, has macro substitution, can
1 execute (or source) other shell scripts, and can inspect its
1 environment.
1
1 Paul Eggert elaborates more:
1
1 With Autoconf, installers need not assume that Imake itself is
1 already installed and working well. This may not seem like much
1 of an advantage to people who are accustomed to Imake. But on
1 many hosts Imake is not installed or the default installation is
1 not working well, and requiring Imake to install a package hinders
1 the acceptance of that package on those hosts. For example, the
1 Imake template and configuration files might not be installed
1 properly on a host, or the Imake build procedure might wrongly
1 assume that all source files are in one big directory tree, or the
1 Imake configuration might assume one compiler whereas the package
1 or the installer needs to use another, or there might be a version
1 mismatch between the Imake expected by the package and the Imake
1 supported by the host. These problems are much rarer with
1 Autoconf, where each package comes with its own independent
1 configuration processor.
1
1 Also, Imake often suffers from unexpected interactions between
1 `make' and the installer's C preprocessor. The fundamental problem
1 here is that the C preprocessor was designed to preprocess C
1 programs, not makefiles. This is much less of a problem with
1 Autoconf, which uses the general-purpose preprocessor M4, and
1 where the package's author (rather than the installer) does the
1 preprocessing in a standard way.
1
1 Finally, Mark Eichin notes:
1
1 Imake isn't all that extensible, either. In order to add new
1 features to Imake, you need to provide your own project template,
1 and duplicate most of the features of the existing one. This
1 means that for a sophisticated project, using the vendor-provided
1 Imake templates fails to provide any leverage--since they don't
1 cover anything that your own project needs (unless it is an X11
1 program).
1
1 On the other side, though:
1
1 The one advantage that Imake has over `configure': `Imakefile'
1 files tend to be much shorter (likewise, less redundant) than
1 `Makefile.in' files. There is a fix to this, however--at least
1 for the Kerberos V5 tree, we've modified things to call in common
1 `post.in' and `pre.in' makefile fragments for the entire tree.
1 This means that a lot of common things don't have to be
1 duplicated, even though they normally are in `configure' setups.
1