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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-05 02:17:52

Hi Michael,

> > I have a <toolset>nmm. A custom generator passes sources though a certain
> > preprocessor, and then changes <toolset> to gcc and compiles/link the
> > targets
> > as usual. But the link-compatability check notices that main target is
> > built with <toolset>nmm and object files are with <toolset>gcc, and
> > issues a warning.
>
> I've been thinking about this one. I think the problem in this case does
> not lie in the link-compatibility warning. The problem is the user is
> forced to switch build targets from nmm to gcc.
> Ideally if 'nmm' uses toolset.inherit from 'gcc' then the whole thing
> should be built using 'nmm'. At present this is not possible.
>
> The problem is that the requirements for 'gcc' will not be used 'nmm'. For
> example:
>
> exe test :
> : <toolset>gcc:<define>"OUTPUT=GCC"
>
> ;
> Here the 'gcc' toolset requirement will not be used for 'nmm'.
>
> For me it would seem logical that toolset.inherit implies this relation.
>
> Do you think this is the correct long term solution??

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.

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.

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

> > So, link-compatibility is half-implemented feature. I'm really not sure
> > I'll have the time to finish it by 2.0 release. And while I'm sorry to
> > remove a feature, especially one that have helped at least one user, I'm
> > going to remove it later this week, unless there are good arguments
> > against removal.
>
> 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.

- Volodya