Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-29 13:10:24

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.

        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.

        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.

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


        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.

        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.

John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper
download Interscript

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