Re: [Boost-build] Q: Why do toolsets do: generators.override ...

From: Vladimir Prus (ghost_at_[hidden])
Date: 2006-02-16 02:50:07

On Tuesday 14 February 2006 17:20, Mark Evans wrote:
> Hi Vladimir
>
> Thanks for the explanation.  I didn't understand the semantics of override
> before  your explanation.  I get the gist of what you are saying and it
> explains the ambiguity errors I was getting in my toolset before I added
> these statements. The override  for searched-lib-generator makes sense. 
> What about prebuilt?  What's the motivation for:
>
> generators.override builtin.lib-generator : xyz.prebuilt ;
>
> Assuming $(xyz) = gcc , is gcc saying that it doesn't want the unix rule
> for prebuilt but rather builtin.lib-generator.prebuilt ?

Yes, that's right. Here's why. Both builtin.lib-generator and gcc.prebuilt 
produce targets of type LIB. We have a way to make generator run only when 
specific property is in property set. In fact of gcc.prebuilt, inherited from 
unix.prebuilt, it will run only when there's <file> property in property-set.

But we don't have a mechanisn to not run a generator if there's specific 
property in property set.

For, if there <file> in property set, and target type is LIB, both
builtin.lib-generator and gcc.prebuilt will be run, which is an ambiguity, 
that must be resolved by generators.override.

With current arrangements, first builtin.lib-generator is invoked, which 
notices the <file> property and tries to build LIB target again. Generators 
have a mechanism to prevent a generator to be choosen twice, so this time 
only gcc.prebuilt is viable, and it's run.

Now that you bring it up, I don't see why change things so that gcc.prebuilt 
override builtin.lib-generator and save one generator invocation. Such a 
change has no effect on regression tests, so it was comitted.

Thanks for pointing out!

- Volodya