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