File: autoconf.info,  Node: Why Not Imake,  Next: Defining Directories,  Prev: Bootstrapping,  Up: FAQ

20.4 Why Not Imake?
===================

     Why not use Imake instead of ‘configure’ scripts?

   Several people have written addressing this question, so adaptations
of their explanations are included 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 is easy to generate large
     makefiles using the ‘#include’ and macro mechanisms of ‘cpp’.
     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 makefiles.  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’
     files tend to be much shorter (likewise, less redundant) than
     ‘Makefile.in’ files.  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.