Jam is not enough

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-02-21 13:29:25

On Wed, Feb 20, 2002 at 04:10:55PM -0000, bill_kempf wrote:

> Jam was never meant as a solution to autoconf, it was meant as a 
> solution to make.

Precisely.  That's the main point I was trying to make.
My secondary point is that replacing make is the easy part.

If I came on strong, it's because I get the feeling that the boost
community thinks that configuration has been solved, or is a
non-issue.  And because the responses to "why not autoconf" is often
"we use jam", which is nonsense.

> A few points.  First, many of us are living fine with the static 
> config headers in Boost today, so we haven't "outgrown" this usage 
> yet.

I wonder if you over-generalize here.  

I'm building the libraries for packaging on Debian (linux).  I did
manage to learn enough Jam to get the 1.26 libraries to build on my
machine, which is an i386.  However, Debian releases packages on about
a dozen different CPU architectures, and the next thing I know they
are all failing to autobuild the package because of
boost/detail/limits.hpp:

 #if defined(__sparc) || defined(__sparc__) || defined(__powerpc__) || defined(__ppc__) || defined(__hppa) || defined(_MIPSEB)
 #define BOOST_BIG_ENDIAN
 #elif defined(__i386__)
 #define BOOST_LITTLE_ENDIAN
 #else
 #error The file boost/detail/limits.hpp needs to be set up for your CPU type.
 #endif

This is nonsense.  Detecting endianness is one of the easiest things
to do with a build-time check.  It turns out that GNU libc has an
<endian.h> header that I can use to get around this, so I patched 
the file to use it.  But the boost headers are rife with things
like

  #if (__BORLANDC__ == 0x550) || (__BORLANDC__ == 0x551)
and
  #if __GNUC__ < 3 || __GNUC__ == 3 && __GNUC_MINOR__ == 0 && __GNUC_PATCHLEVEL__ < 3

This is nonsense.  Debian builds on a number of architectures each
with its own version of GNUCC, and libc, and attendent bugs.  I don't
believe that you are going to be able to track all these compiler bugs
on all the various platforms.  At best, you're going to be reacting to
bug reports.

It's far better to detect the quirks automatically at build time on
the build system.  That gives you a fighting chance to install it on a
novel combination of OS/compiler/stdlib.

And it would help if there weren't stupidities like
        else if $(UNIX)
            PYTHON_VERSION ?= 1.5 ;
            PYTHON_ROOT ?= /usr/local ;

buried deep in the jam files.  I don't want to use version 1.5 and I
don't put it into /usr/local.  These are things that can and should be
probed for.  Ditto for the STLPort libraries that I'm using.

> Second, autoconf can be used to dynamically set up the configuration
> headers today.  See http://www.boost.org/libs/config/config.htm.

True.  I did give it a try when I was getting the 1.26 package into
shape.  It caused some of the libs to fail, so I backed out for now.
I'll give that a try again once I figure out how to get 1.27 built.

> If dynamic configuration becomes necessary then I hope Boost comes
> up with an alternative to autoconf that doesn't require installation
> of a monolithic system on my computer.

Your unstated insight that you don't need all of autoconf is a valid
one.  You do need to be able to dynamically generate a source code
file, run the compiler on it, and detect whether the a valid
executable is produced.  You'd need that to probe for headers,
libraries, and library functions (e.g. gettimeofday).  You may not
need anything more than that.

On the other hand, maybe even that is asking too much
  http://groups.yahoo.com/group/boost/message/9632

And we haven't even touched on installation.  In order to just reach
where autotools is today, Jam needs to be taught how to build shared
libraries on all the platforms, knowledge that is embodied in a 5000
line shell script.

In the end, I am not volunteering to do anything like reimplement a
configure and build system.  Please take these observations as simple
desiderata.  If they sound like criticism, it is only my frustration
at not being able to build 1.27 showing through ;-)

Regards, [and thanks for all the hard work]
-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants