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,
> > is
> > > a *configure* and build (and install) system. They are vastly
> > > different in scope.
> > >
> > > As for the support tools: newer apples (MacOSX) have them,
> > > available for MSwin, I believe that BeOS has them, and of
> > > 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
> > out their knowledge, then it is to convince them we need to
> > 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
> thinks that loads of #ifdefs in header files is scalable hasn't been
> paying attention. This sort of static configuration means that
> is always out of date and you will be playing catch-up forever.
> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk