Re: [boost] Boost build system

From: Toon Knapen (toon_at_[hidden])
Date: 2001-05-29 13:32:57

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

but the target-hardware is of major importance during the build. Since
this will affect the object-file-format, the instruction set, ...

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

OK, thus you consider hardware-info as 'slave' of the build 'toolset'.
This is indeed a good way of looking at it (since hardware-stuff are
mainly options to the compiler). However, users could recognise more
easily a hardware description then a toolset description. Thus for new
users having the hardware description as 'master' might be more easy.
Nevertheless, your approach is technically better. (In the systems I've
build/used, the platform descriptions on the box listed the hardware the
software was ported on and this was also the description used in the
build-system and now have been biased by this approach but as earlier
mentioned, your approach makes more sense)

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

Indeed, the debug flag (-g) or profile flag (-pg) is a standard. But I
was referring to options like the instruction sets to be used (e.g.
-mips4, -mips3 on SGI), the object file format (e.g. -n64,-n32 on SGI).
This information is vital during the build and needs to be known also
when you want to install the binary on some platform.
But as I understand the system now this does not seem a problem anymore.

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

But why not concatenate 'gcc' and 'i585'. Also in case you have multiple
subvariants among which there's no master-slave relation the only option
looks to me concatenating them.

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

> I don't understand this. What is "build-target"?
With build-target I meant the target-platform.

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

I think even things like STLPort can be solved with variants. But the
runtime dependencies on the other hand (like libc6 ...) would be more
difficult. Your system indeed seperates tackles how (compiler) to build
what (the target). Runtime dependencies are yet another dimension : what
is needed to /run/ it.

t