Boost logo

Boost-Build :

From: Michael Stevens (Michael.Stevens_at_[hidden])
Date: 2004-03-03 03:12:16

> Another example is that I have custom
> toolset which is gcc + some extra processing steps. Now, I get numerous
> warnings that the new toolset is not link-compatible with gcc.
> I have a <toolset>nmm. A custom generator passes sources though a certain
> preprocessor, and then changes <toolset> to gcc and compiles/link the
> 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

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

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.

> 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


Michael Stevens Systems Engineering
Navigation Systems, Estimation and
Bayesian Filtering

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at