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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-10 09:39:35

Hi Michael,

> > 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 :-)

Yea ;-)

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

Ok, that makes sense.

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

I think what you ask for is quite reasonable. For the time being, maybe you 
can file an enhancement issue in our tracker? It's

http://zigzag.cs.msu.su:7813/scarab

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

Okay, I'm looking forward. Supporting both versionless init and avoiding the 
problems you raised some time ago would be great.

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

I see.

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

Besides, it appears that no matter what we do about inherited toolset, 
link-compatability warning is still emitted on another use case of mine:

exe test0 : [ asm test0 : test0.cpp : <toolset>nm ] : <toolset>nmm ;

Here, I really need to compile test0.cpp using one toolset and then further 
process it using a different one. And toolsets are not related in any way. 
Now, I get a link-compatibility warning :-(

- Volodya