From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-11 09:50:42
----- Original Message -----
From: "Petr Ovchenkov" <ptr_at_[hidden]>
> Good morning David,
> In boost mail list was discussion 'configure' vs. 'jam'.
We've had various different discussions, including make 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.
I'm not worried about the config problem, so let's leave that aside.
> But when we need to build library, I prefer approach like use
> Boris Fomichev in STLport (I hope you familiar with STLport, and build
> 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.
"any" is a relative term. For example, it does not work on classic MacOS or
VMS. How important this is could be a matter for debate, however.
> As for me, I had first trouble with building jam (jam's build isn't
> clear in second pass, problem come from Jamfiles).
Sorry, I didn't understand that. What did you do, and what result did you
> And second --- in
> understanding boost's Jamfiles.
What did you find difficult to understand?
The intention is for most of the Jamfiles to be very simple.
http://www.boost.org/libs/thread/build/Jamfile is a good example. If you are
crawling through the .jam files in the tools/build directory, I'm not
surprised you had trouble. That's a complicated program designed to make the
If I have failed to make even the Jamfiles simple, then I need to know more
about what you are having trouble with it, so I can fix that problem.
> 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.
I mentioned two above. In any case, the different make-like programs all
have platform-specific quirks which make construction of a portable,
multi-compiler build-and-test system more difficult.
> >> 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).
Like what? I may need to improve the documentation about how to do that.
> >> 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?
Are you volunteering? I don't think it's a good idea to have redundant build
systems, but I would be happy if someone would supply a different system
which satisfies all or most of the goals described at
http://www.boost.org/tools/build/build_system.htm#design_criteria. I would
simply retire Boost.Build if the alternative were easier to use and
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk