Re: [boost] Boost.Build on IBM, SGI & HP

From: Petr Ovchenkov (ptr_at_[hidden])
Date: 2001-10-11 09:12:47

Good morning David,

>>>>> "DA" == David Abrahams <david.abrahams_at_[hidden]> writes:

 DA> We've had lots of discussions on the boost list, starting with
 DA> this one:

 DA> http://groups.yahoo.com/group/boost/message/9568. You might do a
 DA> search on yahoogroups for messages containing "jam make build".

 DA> In my view, there are several reasons:

 DA> 1. Portability. A single make is not available for all platforms,
 DA> at least not without installing a large package like
 DA> Cygwin... and perhaps not even then.

 DA> 2. Power. Make's language for controlling builds makes it very
 DA> hard to do some jobs well. I've had a little experience putting
 DA> together large build systems using make, and found it to be
 DA> extremely difficult once I got past a certain point.

 DA> 3. Less capricious. Maybe it's just me, but I find Make's "lazy
 DA> evaluation" approach to be extremely hard to control and to
 DA> understand. Jam is much more explicit about what it's doing.

In boost mail list was discussion 'configure' vs. 'jam'.
I agree with most arguments that (configure; make) is not a good
solution. When we work with C++, we must find C++-compiler-specific
features. This features are near the same for one compiler
(of the same version), and less platform-dependent.
So the main configuration can be done (and really done) in boost/config/*
By my opinion this is really the best solution.

But when we need to build library, I prefer approach like use
Boris Fomichev in STLport (I hope you familiar with STLport, and build
it): for main classes of compiler/platform we have a specific makefiles,
with reuse of common part where it possible. If we use here common
subset of make's, this will work on any system, without worry about
make or jam or something else binaries.

As for me, I had first trouble with building jam (jam's build isn't
clear in second pass, problem come from Jamfiles). And second --- in
understanding boost's Jamfiles.

 DA> 4. Boost-compatible license. Jam is free for any purpose, and
 DA> freely redistributable.

I really don't know any platform, where present C compiler, and no make
or make-like program.

 >> The complexity is near the same as with make. And presence in
 >> system more than one compiler is a big problem for jam.

 DA> Not at all. I use the boost build system with multiple compilers
 DA> all the time.  Also, with the right Jam code (e.g. what's in
 DA> Boost.Build) it is possible to specify build instructions in a
 DA> platform- and compiler-neutral way, which makes writing Jamfiles
 DA> for new projects much simpler.

This not very easy when you have no experience with Jam, and something
not work (or you want to specify a bit different behavior then default).

 >> Most people has a good experience with maintenance makefiles.

 DA> Not me. Maybe somebody else has a better solution.

May be the solution is to have two build structures, Jam- and
make-based? And everybody will use what he/she like?

With best wishes,

   - ptr