(autocf21.info.gz) Why Not Imake

Info Catalog

(autocf21.info.gz) Bootstrapping

(autocf21.info.gz) Questions

 
 12.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 which 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.
 

Info Catalog

(autocf21.info.gz) Bootstrapping

(autocf21.info.gz) Questions