Re: Why Jam?

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-20 11:10:55

--- In boost_at_y..., "Steve M. Robbins" <steven.robbins_at_v...> wrote:
> 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.

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.  Second, autoconf can be used to dynamically set up the 
configuration headers today.  See 
http://www.boost.org/libs/config/config.htm.  Third, by requiring 
autoconf you *ARE* forcing something on me, and something that I 
can't have in my environment.  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.

> 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

I'm aware of all of this, but it doesn't change the reality that 
autoconf is a Unix tool and using it on non-Unix platforms often 
requires installation of monolithic "unix-like" systems which some of 
us can't do.
 
> > 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!

Jam was never meant as a solution to autoconf, it was meant as a 
solution to make.  If/when we determine there's a real need for 
dynamic configuration I hope we address it in the same way and with 
the same goals as we addressed the need for a build tool.
 
Bill Kempf