Re: [boost] Boost build system

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
> compiler".

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
mean?

> 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
> 'i585-gcc-libc6...'.

If the target hardware is a feature relevant to the toolset, a subvariant
directory will be generated:

bin/gcc/i585/...

> 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
directory chain.

> 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"?

> 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'
> option)
> 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
compiler??

> 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
repeated.

-Dave