Re: [boost] Re: boost.build, msvc, stlport

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-06 07:52:51

===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org)
          email: david.abrahams_at_[hidden]
===================================================

Hi Markus,

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
stated.
# We want to declare the features' values in isolation, instead of all
together
# as with the "feature" rule.
features.implicit toolset variant ; # declare that toolset/variant are
implicit

# 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
not
# 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
says
# 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
as a
# designation directly. A subfeature's values may be set relative to a
particular
# 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
a
# 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
tree,
# 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
be
# 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
element
# 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.

Markus

Info: http://www.boost.org  Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/