Re: [boost] Boost build system

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
subvariant
> > directory will be generated:
> >
> > bin/gcc/i585/...
>
> The main problem with this approach is that
> the classification heirarchy is somewhat arbitrary.

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

-Dave