Free properties not available in conditional rule

[anonymous]

Free properties are not propagated to common-properties2 rule in targets.jam file. Rationale behind this is to optimise caching of already created property-set objects (exactly as stated in rule common-properties, which contains the call).

However, this optimisation causes that free features are not passed e.g. to user-defined rules used for evaluation of <conditional> properties (see example below in the second code listing).

Therefore I would propose to drop this optimisation and propagate also free properties (see code listing below). The other possible solution would be to just pass free properties to the common-properties2 rule and thus make them available to the algorithm, but this will introduce another bug (property-set object from cache will be used even though it contains values created from different free properties).

SOLUTION PROPOSAL

rule common-properties ( build-request requirements )
{
    local props = [ property-set.create
        [ $(requirements).base ]
        [ $(requirements).incidental ]
        [ $(requirements).free ]
    ] ;

    local key = .rp.$(build-request)-$(props) ;
    if ! $($(key))
    {           
        $(key) = [ common-properties2 $(build-request) $(props) ] ;        
    }        
    return $($(key)) ;
}

BUG REPRODUCTION

import feature ;


feature.feature define-prefix : : free ;

rule define-target-os ( properties * )
{
  local define-prefix = [ feature.get-values define-prefix : $(properties) ] ;
  define-prefix ?= "" ;
  local target-os = [ feature.get-values target-os : $(properties) ] ;
  return <define>$(define-prefix)TARGET_OS_$(target-os:U) ;
}


project /root
  : requirements
      <define-prefix>FOOBAR_
      <conditional>@define-target-os
;


exe hello
 : #sources
     hello.cpp
 : #requirements
;

[anonymous]

Attaching relevant discussion on this ticket from mailing list.

Sep 05, 2012; 4:01pm, Jurko Gospodnetić

Hi.

[ ... ]

I do not know if this is intentional or a bug - perhaps someone else can elaborate on that or you can do some more digging in the Boost Build repository yourself.

Code causing this is in the targets.jam module in the

common-properties rule. There all properties except the free ones are passed on to the common-properties2 rule (which in turn calls evaluate-requirements, which then calls the specified indirect conditional rules, all in the same targets.jam module). There is a comment in the common-properties rule mentioning something about this being done as some sort of an optimization, so perhaps this is all just an unfortunate consequence of that (i.e. a fixable bug).

Hope this helps.

Best regards,

Jurko Gospodnetić

Sep 06, 2012; 2:27am, Marek Balint

Hi,

[ ... ]

Thank you for this pointer. I was looking into repository and the common-properties rule was added long long time ago (22. March 2004) in revision 22542 by vladimir_prus. Comment for the revision is "Improve the algorithm for computing build properties.". The only change (except comments and blanks) since then was on last line which now says return [ $($(key)).add-raw $(free) ] ; instead of result = [ ... ] ; However, this change is not present in version 1.49, which I am using and it does not seem to affect this behavior in any way (I tried to edit the file manually and the result is exactly the same - I do not recall really, I am no bjam expert, but isn't effect of those two commands exactly the same and therefore the change is only stylistic one?).

I will try to investigate the issue further, tomorrow, but anyway, any additional comments and/or advice would be much appreciated.

Thanks for help.

.mq.

Sep 08, 2012; 1:19pm, Marek Balint

After further investigation, it seems to be a bug. I created a ticket for it: ​https://svn.boost.org/trac/boost/ticket/7344

The question now is, whether it will be accepted and fixed - if it will be, I can patch my Boost.Build installation and live with my own patch until the problem is fixed in official release. However, if it will not be fixed for some reason, I need to find some reasonable workaround for the problem (obviously, I do not want to end up with patched version forever, since it is straight way to maintenance hell). Which of those two it will be?

.mq.

Sep 13, 2012; 8:41am, Jurko Gospodnetić

Hi.

I do believe this to be a bug, but I like for someone else (Volodya?

Steven?) to comment before actually working on the fix as neither of us is well versed is this part of Boost Build's design and we could be missing something here...

And if it is a bug, and it bugs someone (which it obviously does ;-))

• it will get fixed. :-)

Best regards,

Jurko Gospodnetić

Sep 20, 2012; 9:07pm, Vladimir Prus

I would be scared to make this change ;-)

The key problem with the existing algorithm for computing properties is that:

• The 'default' mechanism for feature is not quite good -- i.e. if you have one compiler that is

gcc for linux and another that is msvc for windows, then no set of default values for <toolset> and <target-os> will express the logic to pick one of those

• There's no way to have non-free features in usage requirements

Fixing that might involve different strategies, including setting some kind of hierarchy of properties so that low-ranked properties can only be derived from higher-ranked properties. Allowing free features to affect anything would make this approach impossible.

I suppose in this case we better solve the bigger problem first.

Volodya