From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-29 09:45:28
----- Original Message -----
From: "Toon Knapen" <toon_at_[hidden]>
> 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.
Not quite. The idea behind all of them is to specify how to build (and test)
libraries, executables, and other targets with a particular toolset. I have
5 compilers (I often say "compiler" when I mean toolset) on my system and
need to be able to compile boost libraries with all of them.
When a given toolset can be used to target multiple platforms (this is not
universal), I have assumed that platform selection could be handled as a
feature which is relevant to that toolset.
> In the 'Build Variants' section you state that variants are
> "feature-value pairs describing how targets should be built for each
they're /sets/ of feature-value pairs
> 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).
For most builds, a large majority of the abstract build parameters can be
common across hardware in my experience. Can you give an example of what you
> 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
If the target hardware is a feature relevant to the toolset, a subvariant
directory will be generated:
> 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.
Think of it this way: a build variant is just a shorthand way of describing
a common set of feature-value pairs. If we didn't have build variants, every
built target would be located at the leaf of an extremely long subvariant
> As a solution, one
> could resort to build-target as being just a collection of variants.
I don't understand this. What is "build-target"?
> 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 | ...
In what case can the front-end be specified independently from the
> 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.
I am not sure yet how best to handle STLport and such. The simplest approach
would be to consider it part of the compiler (e.g. gcc-stlport).
Technically, this is in some sense accurate since the standard library is
part of the C++ implementation. On the other hand, it could cause some
undesirable code repetition as compiler descriptions are repeated, or nearly
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk