From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-03-05 05:23:55
> I think so. The example you give is a resonable one. One possible approach
> would be to make <toolset>nmm composite, which would expand to
> <toolset>gcc. Though having two values of the <toolset> feature scares me
> as -- model where each non-free feature has exactly one value is much
Yes I can imagine this multi value model is going to be somewhat complicated
to implement. A can of worms I suspect! Sometimes it is easier to think up
ideas then to implement them. You might have notice in this case I didn't
volantear to submit a patch :-)
> That would also require changes in generator selection mechanism. Now,
> tooset.inherit will cause two similiar generators to exist, one with
> <toolset>gcc as required property and another as <toolset>nmm.
> So, if we have <toolset>nmm <toolset>gcc in build properties, both
> generators will be selected, and that's ambiguity.
I understand this situation differently. From the users perspective "bjam nmm
gcc" would build two completely different (and independent) targets. They are
after all different toolsets. For example nmm may be a version of gcc for
cross compiling to a different target. Therefore from a build target
perspective the two <toolset> properties are independent.
The inheritance relationship (multi-valued toolset property) is important only
when requirements and usage-requirements are matched for main targets. From
the users perspective this allows me to specify one set of requirements for
all gcc and gcc derived toolsets.
I hope this makes sense even if it may be non trivial to implement!
> > For me it has many advantages. I have had many occasions where I want to
> > change the 'init' function for a toolset. At present toolset.inherit
> > can't be used for the same reason.
> I see. BTW, while we're at it, some time ago you was going to clean up
> gcc.init? Did you have any luck? Where there any show-stoppers?
I have a gcc-ms.jam that I use to run various versions gcc out of specified
directories. The code is however very simple minded.
To implement it I made the version parameter mandatory. This would be
problematic given the current default toolset initialisation. On my todo list
I still have implement "Improving BBv2 versioned toolsets" which I hope to
contribute in the future.
import toolset : flags ;
import feature ;
import gcc ;
# Initializes the gcc toolset with a identified version and path
rule init ( version : name ? : path ? )
name ?= "g++" ;
path ?= "" ;
feature.extend-subfeature toolset gcc : version : $(version) ;
modules.call-in gcc : flags gcc NAME <toolset>gcc-$(version) :
This also show the mechanism by which I overide existing toolset without using
> > Seem like unnecessary work! I'm sure you will want to put it back again
> > in the future.
> Probably. But removing is very simple operation. What I'm trying to avoid
> is making users depend on half-finished feature which might be finished in
> very distance future.
I see, I think you are right.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk