From: Daniel Einspanjer (deinspanjer_at_[hidden])
Date: 2006-03-01 10:43:12
I'd like to ask a follow-up question for my further education if I may. An
answer simply pointing to relevant documentation is just fine if I've
"Vladimir Prus" <ghost_at_[hidden]> wrote in message
> On Wednesday 01 March 2006 02:22, Daniel Einspanjer wrote:
>> rule get_extra_source ( properties )
>> local cust_name = [ $(properties).get <customer> ] ;
>> return [ glob fubar-$(cust_name).cpp ] ;
> rule get_extra_source ( properties * )
> local cust_name = [ feature.get-values <customer> : $(properties) ]
> local s = [ glob fubar-$(cust_name).cpp ] ;
> return <source>$(s) ;
Why do some rules need ( properties * ) as a parameter instead of (
properties ) ?
I assume that if the parameter is ( properties * ) then the [
feature.get-values <customer> : $(properties) ] form must be used to extract
something from it whereas if the parameter is just ( properties ) then [
$(properties).get <customer> ] is the right way to extract a value. Is this
a correct understanding?
I wrote this rule to be used in a <tag> call and I based it almost exactly
off of the test in tag.py.
rule make_customer_branded_name ( base_name : type ? : properties )
local cust_name = [ $(properties).get <customer> ] ;
return [ virtual-target.add-prefix-and-suffix
$(base_name)-$(cust_name) : $(type) : $(properties) ] ;
Both this rule and the conditional rule are invoked in the same manner, in
the same requirements section of a target. What controls the parameters
passed in to them?
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