🚀 go-pugleaf

   There are two families of GNU configurators.  The bigger one is used
   for GNU C/C++, GDB, C library, etc. and, so far that I know, is not
   yet completely packaged as a stand-alone product.  The smaller one is
   getting used for almost everything else, get it from prep.ai.mit.edu
   in pub/gnu as autoconf-1.0.tar.Z.  There is an on-going effort to
   merge the two configurators, I cannot predict if and when this effort
   will succeed.

Actually, there are 3 families.  There is gcc's configure script,
Cygnus configure, and a bevy of autoconf generated ones.  There are
also some oddballs (sorry Brian & Roland), like bash and glibc, which
satisfy the basic requirements of the GNU standards but are of a
completely different heritage.  While Cygnus configure is not
distributed standalone, it's not that hard to take what exists and
write the appropriate configure.in files for a new program.  There is
documentation (configure.texi) in every release that comes from Cygnus
(gdb, libg++, binutils, etc).

The two main families are indeed Cygnus configure and Autoconf.  Each
of which serves a useful place.   In a nutshell, Autoconf does a
number of configure time feature tests to determine the compilation
environment, such as whether or not a header file exists, or if some
language feature is available, and the like.  Cygnus configure allows
you to write shell fragments that do different things based on the
host/target triples, usually getting Makefile fragments from a
database.  

Some programs don't need to be cross-configured (configuration
dependent on the target, not the host).  These programs can be
configured quite well with Autoconf.  Other programs (gcc, gdb) often
need to be cross-configured, where a database model is needed, since
the target environment may not exist yet, or may not be available
(embedded cpu's in toasters, say).


      1) I want to use one configuration script for configuring all
      software packages.

   Unless you have inordinately complex needs, Autoconf should suffice.

This is generally true, unless your program has cross-compilation
needs, in which case Autoconf is not a viable option.


      I am building GNU software for native use on a SPARCstation 2, and
      also as cross-development tools for the Motorola 68K architecture.
      I would like to have the native configuration separate from the
      cross configuration, so that files don't get overwritten each time
      I run configure

   Autoconf is geared towards multiple installations in different
   subdirectories and cross configurations; the former certainly works
   nicely, I have no experience with the later; but who knows, Autoconf
   might be your best bet.  Your true configuration sources are short
   configure.in files, which autoconf expands, using GNU m4, into
   configure scripts which you then include in your distributions.

 
Both autoconf and Cygnus configure support the -srcdir option, which
allows a single read-only source tree and compilation into any number
of object directories.

For background, Cygnus maintains a large (60Mb or so) source tree,
consisting primarily of GNU software.  Our entire tree (with one
exception) is either using Cygnus configure or autoconf.  Cygnus
configure at the top level can see that a subdirectory has a configure
script of its own and will use that instead if it's available.   The
exception is patch, where we have placed a little wrapper around the
metaconfig generated Configure script.  

Above this source tree, we have a Makefile which will automatically do
a 3-stage build (build stage1 with native tools, stage2 with stage1,
and then stage3 from stage2 tool) for any host native platform, and
also do any supported host-target pair for cross-compilation.

The two configure packages work well together, and a general consensus
has been reached that the two should be merged into a single package.
The model that this merged configure would use is this: if a database
entry exists for this host or target, use that; otherwise go out and
do the appropriate feature tests.  Now that the 'configure cabal' has
more or less decided on this model, it needs to be implemented.  No
one is doing this work yet.


  david d 'zoo' zuhn |  
    cygnus support   |  "Man made it, man can fix it."
    zoo@cygnus.com   |  		-- anonymous biker in South Dakota