From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-29 09:21:24
----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> That's my thoughts too. Having separate platform-dependent 'config'
> on one side and a monolithic build description file with embedded
> platform-specific options on the other just doesn't feel right.
I think the difference is one of quantity of information. Unfortunately,
configuration info still tends to be large, and regardless it can be done
once for an entire project. Most targets will require little or no
platform-specific tweaking in the build system. It doesn't feel right to
litter the world with tiny files just to handle the fact that, e.g. one
compiler needs -DNO_STD_MINMAX or some such for a particular target... and
much of that sort of thing can be done with header files if we want to, so
the solution Vesa proposed for config.hpp is still available to us.
> But overall the build system looks very promising and reasonable. Also,
> the requirements are very clear and appropriate.
> One requirement I would
> like to add, though, is a possibility to specify a different set of
> for the same target depending on the build variant (I am almost sure
> already possible, just want to see it as a requirement).
Well, no, it's not possible yet. I'm not sure it's neccessary, since the
same effect can be accomplished via #if directives embedded in the source
files. I didn't consider it a high-priority item for that reason, but it
certainly has some appeal from an aesthetic POV.
Since a few people with CVS write permission seem to be interested in the
build system I would like to check it into CVS in the hopes that you will
help bring it to maturity. Niceties like the ability to select different
sources for different platforms take some effort to achieve.
We also need to make a few changes to the Jam sources to support unix-style
paths under Macintosh MPW (these changes are simple; I know what to do) and
Win95/98 (someone else has already done this for us but it is not in the
official sources yet). The only question is whether we should use the
Perforce public depot (yet another publicly-available source control system)
or our own CVS system to manage the work. I am inclined to use CVS because
there's no new learning curve, but as an open-source developer I also feel
obliged to respect the process they have set up for Jam. The perforce
developer selects fixes from the public depot and re-integrates them back
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk