Re: [jamboost] link-compatibility poll: results and feature removal

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-03-05 05:23:55

Hi Volodya,

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

"gcc-ms.jam"
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) : 
$(path)$(name) ;
}

This also show the mechanism by which I overide existing toolset without using 
inherit.

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

Michael