Re: [boost] Boost build system

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-29 14:08:53

----- Original Message -----
From: "Toon Knapen" <toon_at_[hidden]>

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

I think you misunderstand. When I say "abstract build parameters" I mean
that flags like "-pg" or "-g" are represented by normalized features so that
the particulars of how to acheive debugging or profiling on a given toolset
are handled by the toolset description.

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

Whew!

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

I don't understand your interest in "master" and "slave" roles. I don't
think of anything in the system in those terms. In any case, the parts *are*
concatenated: into elements of a directory hierarchy. One reason not to
string them all together into a single name is that some platforms have
filename length restrictions.

I know some people want the ability to generate directories with names like
gcc-i585-pc-linux-gnu (or whatever). If this is important to enough people,
hopefully someone will step up and implement this option. It should be at
least possible, but it won't work for all platforms.

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

OK.

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

Wait 'till you see the Jam code; then tell me if you still think so...

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

Yes, that could get interesting. We'll see what happens when we try to
re-structure the regression test framework around the build system :-)

-Dave