Boost logo

Boost :

From: Steve M. Robbins (steven.robbins_at_[hidden])
Date: 2002-02-20 10:43:04

On Wed, Feb 20, 2002 at 02:20:00PM -0000, bill_kempf wrote:
> --- In boost_at_y..., "Steve M. Robbins" <steven.robbins_at_v...> wrote:
> > On Wed, Feb 20, 2002 at 08:16:22AM -0500, nbecker_at_f... wrote:
> > > Portability. autoconf+automake require lots of support tools
> that may
> > > not be present on non-unix systems.
> >
> > True, but: "jam" is only a build system, while "autoconf+automake"
> is
> > a *configure* and build (and install) system. They are vastly
> > different in scope.
> >
> > As for the support tools: newer apples (MacOSX) have them, cygwin is
> > available for MSwin, I believe that BeOS has them, and of course all
> > unix systems have them. That covers the systems listed in
> >
> Many of us work in shops that restrict what can be installed on a
> system. It's easier to convince them to let us install a single,
> small executable (jam.exe), or in some cases just boot strap Jam with
> out their knowledge, then it is to convince them we need to install a
> monolithic system such as cygwin. More over, why force a Unix
> interface (cygwin) on non-Unix programmers?

I don't want to force anything on anyone.

I am simply making the point that "jam" is but one part of the
solution. The smaller part, in my estimation.

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.

There's a short history of configuration (in the unix world)
in the Goat book:

A work-in-progress by Erez Zadok summarizes the main problems of
configuring a portable system, and how autoconf addresses them:

And finally, there is the classic "ifdef considered harmful" by Spencer:

> The reality is, many of us simply can't use autoconf+make,

Installing extra tools is a burden. I don't want to minimize it.
I point to GNU autoconf out of ignorance: I don't know any other
tool that accomplishes the same goal.

Configuration is a hard problem, and "jam" is not the solution. If
you folks can reimplement what GNU autoconf does in a new tool, then
more power to you!

Don't forget to steal
the good ideas of GNU autoconf, and the Software Carpentry competition:


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at