From: Daniel Einspanjer (deinspanjer_at_[hidden])
Date: 2006-03-13 10:21:17
"Vladimir Prus" <ghost_at_[hidden]> wrote in message
> Boost.Build will find all generator invocation sequences from INI to CPP,
> subject to restriction that no generator can be invoked twice. This gives:
> (1) INI -> CPP
> (2) INI -> CPP -> CPP
> and it's an ambiguity. The possible solution is to make CPP -> CPP
> run only when explicitly needed. For example:
> 2. You can make customerinfo-generator demand a very specific source type,
> use cast. Basically, that's what you tried to did, but you should not
> CUSTOMERINFO from CPP. If you do, then sequence (2) above will still be
> found, because CUSTOMERINFO types inherits all generators for from type
This was exactly the problem. Making CUSTOMERINFO not inherit from CPP
makes the generators work regardless of import order. I'm sorry you had to
struggle with me so long to get a clear explanation from me.
> 1. If the generator should be invoked only when some property, say
> is in build properties, use this:
In our case, <customer> is always in the build properties. It is a global
feature that defaults to our "internal" customer name if none were
> generators.register [ new customerinfo-generator customerinfo.transform :
> CUSTOMERINFO : CUSTOMERINFO : <allow>customerinfo.transform ] ;
> and add <allow>customerinfo.transform to requirements if you want this
> generator to run. The <allow> property is the standard one. You can use a
> helper rule to automatically add this property when declaring targets:
> rule customerinfo-transformed ( name : sources * : requirements * .. )
> customerinfo $(name)
> : $(sources)
> : $(requirements) <allow>customerinfo.transform
This example of using <allow> is in my notebook as being potentially useful.
:) I'm not sure how the helper rule helps though. Where would you invoke
the rule? In the requirements section of a target that consumes the
> I don't know which method is best for you, but all should work.
To be completely frank, I acknowlege these generators are a trifle
over-engineered. I could have easily done everything in them with a simple
I created them to both better my understanding of the BB system and to
demonstrate the power and flexibility of the system to our dev team.
> Speaking about imports order -- that's still a bug in Boost.Build, I'll
> into it.
Hopefully it will be a bug fix that enhances the reliability of BB rather
than just fixing this one nit. :)
Thanks again for your persistent help with this issue.
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