From: Toon Knapen (toon_at_[hidden])
Date: 2001-05-29 07:44:58
David Abrahams wrote:
> I am actually interested in uses beyond boost (we need a good cross-platform
> build system at work), so please feel free to think "outside the boost box"
> when reading this. I look forward to your comments. I hope to finish this
> document and post the Jam code in the next few days.
I'm a little bit confused about the distinction between the
specification of platform, compiler, variants and subvariants. The idea
behind all of them is to specify how to build the libraries for a
specific type of hardware.
In the 'Build Variants' section you state that variants are
"feature-value pairs describing how targets should be built for each
compiler". I think it's hard to seperate how to build and for which
hardware to build (what to build is in the target and can be seperated).
Thus I think also the target-hardware should be taken into account at
this stage as well as the (system)libraries the boost-component relies
on. Thus now you have entries like 'gcc' and 'kai' in the generated
directory structure but I guess this will become more complex like
Looking at all this complexity, the distinction between variants and
subvariants thus not remain clear (to me) since it is difficult to
identify 'master' and 'slave' among all these facets. As a solution, one
could resort to build-target as being just a collection of variants. To
specify more the variants I'm thinking about here a short list from the
top of my head :
CONFIG = debug | release | profile (profile for the typical '-pg'
PROC = i585 | i686 | mips12000 | ...
OBJECTFILEFORMAT = 032 | n32 | n64 | PA2.0 | PA1.0 | ... (these are the
flags for SGI and HP)
COMPILER= gcc | ...
FRONTEND = EDG | ...
and finally some library-dependencies could go into this like which STL
is use (STLPort, SGI, ...), which version of the c and C++ runtime
should be used etc.
-- Toon Knapen toon_at_[hidden] Si-Lab http://www.si-lab.com Albert I laan 113 B-1800 Vilvoorde, Belgium tel: +32/486/149048
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk