From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-29 21:29:44
David Abrahams wrote:
> > > 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.
The problem isn't implementing a solution, but actually
_finding_ one. One of the problems using libranies like boost
in production environments is that the components are often
independent .. except for that silly config file,
which conflicts with the sites own config file: even if the
components are conceptually decoupled, the implementation
is monolithic: you take the whole of boost or leave 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?
So an attempt to decouple configuration information,
and represent that in a modular way by directory structures,
is bound to run into limitations. [It is only a partial
> > 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.
Of course it is an option. Do you support libraries
written in K&R C?? No. But you'll support compilers that
don't support member templates .. for a while, anyhow.
I think it is reasonable to support
'latest compiler' for each platform, and perhaps
'one before that'. But you can argue anyone that is
three compiler versions out of date ought to upgrade.
You can ALSO argue that there should be
another boost version: ISO BOOST. This system
doesn't provide any support for non-ISO systems
at all. It will be a useful challange for compiler
vendors, and the best preparation for submission
to the committee.
> I am not trying to solve the 'config' problem;
> only the build problem.
Isn't this the same thing?
> I am certain I have mentioned this before:
> requiring Python was deemed by
> the boost membership to be unacceptable.
Then you have to do it in C/C++
using 'system' calls.
-- John (Max) Skaller, mailto:skaller_at_[hidden] 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk