Re: Building Subversion 1. on OS X 10.4 fails
From: K. Richard Pixley <rich_at_noir.com>
Date: 2005-05-18 01:11:48 CEST
Still fails for me. "-lpthread is not an object file" error from libtool.
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:
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.
--------------------------------------------------------------------- To unsubscribe, e-mail: firstname.lastname@example.org For additional commands, e-mail: email@example.com Received on Wed May 18 01:13:47 2005
This is an archived mail posted to the Subversion Users mailing list.