Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-29 13:59:12

----- Original Message -----
From: "John Max Skaller" <skaller_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 29, 2001 2:10 PM
Subject: Re: [boost] Boost build system

> David Abrahams wrote:
> > If the target hardware is a feature relevant to the toolset, a
> > directory will be generated:
> >
> > bin/gcc/i585/...
> The main problem with this approach is that
> the classification heirarchy is somewhat arbitrary.

I don't think this is a serious problem for boost, but it might prevent some
people using the system outside boost. Hopefully, someone who needs a better
solution will step up to implement it.

> A more perverse problem is that this tends to work well
> for categorical products -- orthogonal features -- but many
> features interact in ways that a tree structure doesn't handle well.
> For example, if you have compiler/library values, they're likely
> not orthogonal: some library features only work on some compilers.

So what?

> In the end, the interaction is extremely complex.
> The best solution I know of is Standardisation. And that means
> DROPPING support for non-Standard systems.

Not an option for boost, I'm afraid.

> > > COMPILER= gcc | ...
> > > FRONTEND = EDG | ...
> >
> > In what case can the front-end be specified independently from the
> > compiler??
> The case given: EDG is only a front end.
> You still need gcc to compile the generated C code.

That may be easy to encapsulate as part of the build tool description.
Still, it does introduce an additional intermediate target which must be
accounted for.

> -------------------------------------------------------------
> There is another solution to the 'config'
> problem. Because config is so complex, macros and directories
> of supported configs end up not really making it.

I am not trying to solve the 'config' problem; only the build problem.

> The solution is to use executable code to build
> the sources and compile them. I do this myself, using
> a literate programming tool. For boost, a more acceptable
> solution might be to provide a build script written
> in Python. It can take platform data and figure out
> how to build a system.

I am certain I have mentioned this before: requiring Python was deemed by
the boost membership to be unacceptable.

Anyway, the choice of language doesn't really change the nature of the


Boost list run by bdawes at, gregod at, cpdaniel at, john at