From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-03-05 02:17:52
> > 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
> 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
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