Re: [Boost-build] conditional rules: arguments

Subject: Re: [Boost-build] conditional rules: arguments
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-09-14 04:56:58

On Thursday 10 September 2009 Gaydov Victor wrote:

> >  look at 
> > the Jamroot attached to:
> > 
> > http://article.gmane.org/gmane.comp.lib.boost.build/21130
> 
> thanks, i've read, ..
> 
> > It will help if you provide an example explaining
> > what you mean. 
> 
> > You could define custom features for this purpose
> 
> yes, and i'm trying to do this:
> 
>  import feature ;
>  feature.feature f1 : : free ;
> 
>  rule c1 ( p * ) { echo $(p) ; }
>  lib a : : <f1>value <conditional>@c1 ;   # no <f1> in $(p)
> 
> (it works only if <f1> is in default-build)
> 
> > What are "current properties"? During property resolution process the
> > rule specified with the <conditional> is called with the current property
> > set. The result is that added to that current property set and becomes
> > build properties.
> 
> so, i found the place when i lost <f1>:
> 
>  build/targets.jam:common-properties()
>  .....
>  local non-free = [ property-set.create 
>         [ $(requirements).base ]  [ $(requirements).incidental ] ] ;
>  .....
>  $(key) = [ common-properties2 $(build-request) $(non-free) ] ;
>  .....
> 
> evaluate-requirements() is called in common-properties2(), without free
> features. it works for non-free, i just didn't try before, sorry.
> 
> now my question is: why can't i pass free features to
> conditionals and is it possible ? :)

Victor,

the "general" reason is that free features tend to be used for 'raw' things
that are passed to the underlying thing, and therefore are not considered in
many contexts.

I don't know if in this case, specifically, passing free features to conditional
functions will break anything or not. Can you let me know your actual use case,
so that I can properly consider this behaviour?

Thanks,
Volodya