Re: [boost] Re: Why Jam?

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

Hello,

On Thu, Feb 21, 2002 at 07:18:19AM -0500, John Maddock wrote:
 
> >The main problem with portability is not the lack of a common build
> >tool, but the lack of a maintainable configuration system.  Anyone who
> >thinks that loads of #ifdefs in header files is scalable hasn't been
> >paying attention.  This sort of static configuration means that boost
> >is always out of date and you will be playing catch-up forever.  This
> >is one reason autoconf won over imake.
> 
> Point taken, but:
> 
> * Many like things to just plain work out of the box, without a configure
> step.

Sure, that would be great.  

On the other hand, boost manifestly does NOT work out of the box on
anything but a handful of platforms on which it has been tested --- try
building on an m68k machine running linux.  Wouldn't it be better to
work *with* a config step on *more* platforms?

> * there are some platforms where autoconf style configure scripts just
> don't work - Borland C++ on Win32 for example (no not even with a cygwin
> shell).

The solution we chose for CppUnit (cppunit.sf.net) is to ship a static
configuration file for those platforms who can't (or installers who
won't) run a configuration script.  Those who are not so handicapped can
run configure.

That is *almost* what boost is doing now with the autogeneratable
user.hpp file.  The crucial difference is that all the headers need to
be purged of things like "#if __i386" or "#if BORLAND_VERSION < 3",
and instead use things like "#if HAVE_FUNCTION_FOO" and 
"#if HAVE_DEFECT_BAR" *only*.

Test features, not platforms.

> * the auto* tools do not address multiple build configurations (most win32
> compilers ship with multiple (incompatible) runtime libs for example - we
> need one build of each boost lib for each runtime variant).

That's a trivial shell script away, on the platforms that allow you
to script such things.  But this is straying away from the configure
tool back to the build tool.  The issues are orthogonal.

> * things like lib tool is not (yet) set up for C++ libraries - yes I know
> it works with gcc, but not as far as I know with unix compilers that use
> link-time instantiation or template repositories.  Last time I looked the
> docs cautioned against use with C++ libs.

Again, this is a build-tool issue.  However, I did ask about this on
the libtool list, and the answer is that the docs are likely out of
date with reality.  The main issue is with instantiating static
objects.  If you don't do that, you should be fine.  If you do have
static objects, you are fine on lots of platforms (e.g. when using
GCC), but some may give you trouble on others.  At any rate, it's a
whole lot better than the current procedure for building shared libs.

> * There is an optional autoconf based configure script for boost if you
> want it. It's currently under used IMO, but it does work pretty well.

Yes.  I'm going to try it again.  How well maintained is it vis-a-vis
the rest of the headers?

-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