Boost C++ Libraries: Ticket #7344: Free properties not available in conditional rule https://svn.boost.org/trac10/ticket/7344 <p> 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). </p> <p> However, this optimisation causes that free features are not passed e.g. to user-defined rules used for evaluation of &lt;conditional&gt; properties (see example below in the second code listing). </p> <p> 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). </p> <h2 class="section" id="SOLUTIONPROPOSAL">SOLUTION PROPOSAL</h2> <pre class="wiki">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)) ; } </pre><h2 class="section" id="BUGREPRODUCTION">BUG REPRODUCTION</h2> <pre class="wiki">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 &lt;define&gt;$(define-prefix)TARGET_OS_$(target-os:U) ; } project /root : requirements &lt;define-prefix&gt;FOOBAR_ &lt;conditional&gt;@define-target-os ; exe hello : #sources hello.cpp : #requirements ; </pre> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/7344 Trac 1.4.3 anonymous Tue, 25 Sep 2012 20:04:16 GMT <link>https://svn.boost.org/trac10/ticket/7344#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/7344#comment:1</guid> <description> <p> Attaching relevant discussion on this ticket from mailing list. </p> <h2 class="section" id="Sep0520124:01pmJurkoGospodnetić">Sep 05, 2012; 4:01pm, Jurko Gospodnetić</h2> <blockquote> <p> Hi. </p> </blockquote> <p> [ ... ] </p> <p> 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. </p> <blockquote> <p> Code causing this is in the targets.jam module in the </p> </blockquote> <p> 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). </p> <blockquote> <p> Hope this helps. </p> </blockquote> <blockquote> <p> Best regards, </p> <blockquote> <p> Jurko Gospodnetić </p> </blockquote> </blockquote> <h2 class="section" id="Sep0620122:27amMarekBalint">Sep 06, 2012; 2:27am, Marek Balint</h2> <p> Hi, </p> <p> [ ... ] </p> <p> 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?). </p> <p> I will try to investigate the issue further, tomorrow, but anyway, any additional comments and/or advice would be much appreciated. </p> <p> Thanks for help. </p> <p> .mq. </p> <h2 class="section" id="Sep0820121:19pmMarekBalint">Sep 08, 2012; 1:19pm, Marek Balint</h2> <p> After further investigation, it seems to be a bug. I created a ticket for it: <a class="ext-link" href="https://svn.boost.org/trac/boost/ticket/7344"><span class="icon">​</span>https://svn.boost.org/trac/boost/ticket/7344</a> </p> <p> 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? </p> <p> .mq. </p> <h2 class="section" id="Sep1320128:41amJurkoGospodnetić">Sep 13, 2012; 8:41am, Jurko Gospodnetić</h2> <blockquote> <p> Hi. </p> </blockquote> <blockquote> <p> I do believe this to be a bug, but I like for someone else (Volodya? </p> </blockquote> <p> 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... </p> <blockquote> <p> And if it is a bug, and it bugs someone (which it obviously does ;-)) </p> </blockquote> <ul><li>it will get fixed. :-) </li></ul><blockquote> <p> Best regards, </p> <blockquote> <p> Jurko Gospodnetić </p> </blockquote> </blockquote> <h2 class="section" id="Sep2020129:07pmVladimirPrus">Sep 20, 2012; 9:07pm, Vladimir Prus</h2> <p> I would be scared to make this change ;-) </p> <p> The key problem with the existing algorithm for computing properties is that: </p> <ul><li>The 'default' mechanism for feature is not quite good -- i.e. if you have one compiler that is </li></ul><blockquote> <p> gcc for linux and another that is msvc for windows, then no set of default values for &lt;toolset&gt; and &lt;target-os&gt; will express the logic to pick one of those </p> </blockquote> <ul><li>There's no way to have non-free features in usage requirements </li></ul><p> 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. </p> <p> I suppose in this case we better solve the bigger problem first. </p> <p> Volodya </p> </description> <category>Ticket</category> </item> </channel> </rss>