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"
> > 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:
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk