Re: Building Subversion 1.[12] on OS X 10.4 fails

From: K. Richard Pixley <rich_at_noir.com>
Date: 2005-05-18 01:11:48 CEST

Stephen Davis wrote:

CC=gcc-3.3 GXX=yes ./configure

Still fails for me.  "-lpthread is not an object file" error from libtool.

Out of curiousity, what better alternatives exist?  I've seen makefiles that "just work" (which is impressive) but I'm not familiar with any other autoconf-esque mechanisms.

Configuration systems can be broken down into two basic categories.  In one category, a set of configuration parameters is manually crafted, stored, distributed with the package, and then recalled prior to compilation.  If there is any testing done at all, it's done on a very macro level in order to guess which parameter set will be selected.

In the other category, a set of configuration parameters are generated on the fly prior to each compile using a set of rules which have been shipped with the package.  Each parameter may require multiple tests in order to determine a suitable value and each nested package will generally retest in order to generate parameter values in terms it understands.

Autoconf generates.  Larry Wall's Configure also generated.  And I think setup.py also generates, although most of the heavy lifting has already been done for setup.py by whoever ported python.

Autoconf further suffers from the problem that autoconf scripts are generated using a tool whose version isn't kept in sync with your product.  So trying to port an old package can be nightmarish when new versions of autoconf don't regenerate your scripts and old versions of autoconf aren't available or can't manage the newer tests.

The database approach, has advantages:

• way, way, way faster being basically a fixed time operation to set a series of predetermined constants
  
• can exactly reproduce a particular configuration numerous times
• fails in clear and obvious ways for unsupported configurations
  
• can be configured by hand if necessary
• can be configured on a machine other than the one used for building, (ie, cross or third party compilations)
• simpler
• avoids unnecessary and redundant testing for nested instantiations
  

While it's true that a database system will fail on many minor issues, those issues are minor to fix.  Add a new row to the database and change the parameter you need.  Even moderate issues requiring new parameters are minor to fix since you know that all previous systems worked without it.  The learning curve here is minor or trivial for anyone who understands basic software building concepts like gcc & make.

Cygnus configure, (which I originally wrote and is still in use for gdb and binutils, I think), implements the GNU "configure" interface using a database approach.  Cygnus configure predates autoconf by a year or so.  Cygnus configure can support cross configuration, third party configuration, nesting, and it does it quickly and completely using a single /bin/sh script with table data stored in simple makefile fragments and/or symlinked source alternatives, (ie, t-macox.h vs t-solaris.h).

This means that Cygnus configure essentially forks every time a package that uses it ships, but that's ok because Cygnus configure is v7 compatible /bin/sh - it runs anywhere, or at least on a much wider variety of platforms than can possibly be supported by autoconf+m4+autotools+etc.  It's both source and executable and doesn't need to be rebuilt.  When necessary, you can simply edit an old copy to add a feature to an old distribution.  Of course, changes to Cygnus configure are rare, since it doesn't really know anything about your package's features anyway - those are kept in your source fragments.

Autoconf works well if you believe that a very small number of packages will ever be compiled on a very large number of different types of systems, particularly so if the types of systems are so dynamic that they can't be defined.  But in fact, what we've seen over the years is a drastic curtailment in the number of types of systems and a literal explosion in the number of packages.  Basically we're down to windows, macosx, and linux, with occasional allowances for bsd systems or solaris.  In past years I could literally list over 50 operating system distributions each with multiple versions.  And the number of available packages is just simply so large as to be uncountable.

--rich
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org Received on Wed May 18 01:13:47 2005