Re: [boost] Re: Why Jam?

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
> > http://www.boost.org/status/compiler_status.html.
> 
> 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:
  http://sources.redhat.com/autobook/autobook/autobook_6.html#SEC6

A work-in-progress by Erez Zadok summarizes the main problems of
configuring a portable system, and how autoconf addresses them:
  http://www.cs.columbia.edu/~ezk/research/autotools/node2.html

And finally, there is the classic "ifdef considered harmful" by Spencer:
  ftp://gatekeeper.dec.com/pub/news/c/doc/usenix92.ps.Z

> 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 
  ftp://ftp.enst.fr/pub/unix/lang/C/c-tips/steal.ps.gz
the good ideas of GNU autoconf, and the Software Carpentry competition:
  http://sc-archive.codesourcery.com/sc_config

Regards,
-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