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