From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-06 07:52:51
David Abrahams, C++ library designer for hire
C++ Booster (http://www.boost.org)
I am working on some ideas for a new interface for "everything", so we can
handle some of these things more consistently. Ideas are still half-formed,
but take a look:
# toolset and variant are weird: they are features that aren't explicitly
# We want to declare the features' values in isolation, instead of all
# as with the "feature" rule.
features.implicit toolset variant ; # declare that toolset/variant are
# this will be part of the result of loading the msvc toolset
features.extend toolset : msvc ;
# declares <toolset-version> as a subfeature of <toolset>. A subfeature is
# translated into a new path element, but is instead appended to the feature
# name with a dash separator, as in "gcc-3.0.1". The "optional" designation
# that the feature may be omitted.
features.subfeature toolset : version : optional ;
# Though maybe "optional" makes more sense here than above
# When a feature is declared implicit, any value of the feature may be used
# designation directly. A subfeature's values may be set relative to a
# value of the "superfeature", thus "gcc" below.
features.feature gcc/version : 2.95.2 2.95.3 2.96 3.0 3.0.1 : optional ;
# this will be executed as a result of declaring the "debug" variant
features.extend variant : debug ;
# this might be supplied by the build system, but also might be included in
# user's configuration file. It is legitimate because build-variant is an
# implicit feature.
features.default build-variant : debug ;
# ---the following might appear in stlport.jam --
# "optional" below is supposed to take the place of sticking the feature in
# every variant.
features.implicit library : optional ;
features.extend library : stlport ;
# declare the features which generate directories at the top of the build
# and the order in which the directories are generated.
features.feature stlport/version : 4.0 4.5 : optional ;
features.feature stlport-iostreams : on off : optional ;
# force the first few features in the sort order for target directory
# generation. Since library is labelled "optional" above, no directory may
# generated for the library if it is not overridden.
build.top-features toolset library variant ;
# build specification -
# The variants and subvariants built are determined by combining each
# with all other elements whose features do not overlap.
# this builds: gcc-3.0.1/stlport/debug, msvc/stlport/debug, msvc/debug
build = gcc-3.0.1/stlport msvc/stlport msvc debug ;
----- Original Message -----
From: "Markus Schoepflin" <markus.schoepflin_at_[hidden]>
I think we even must make possible the following:
TOOLS = msvc ; # Wich master toolset to use.
BUILD = debug <msvc-version>6 <stlport-version>4.5 ;
and you will get something like msvc-6-stlport-4.5 for the toolset
name. This would allow for parallel usage of different compiler
versions and STLport versions.
It doesn't quite feel right, yet, but I hope you get the idea.
[snip questions about STLport issues]
I posted a mail in the STLport forum. No answer so far.
Info: http://www.boost.org Unsubscribe:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk