Re: [Boost-bugs] [Boost C++ Libraries] #7344: Free properties not available in conditional rule

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #7344: Free properties not available in conditional rule
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-09-25 20:04:16

#7344: Free properties not available in conditional rule
-------------------------------+--------------------------------------------
  Reporter:  anonymous         |       Owner:  vladimir_prus
      Type:  Bugs              |      Status:  new          
 Milestone:  To Be Determined  |   Component:  build        
   Version:  Boost 1.52.0      |    Severity:  Problem      
Resolution:                    |    Keywords:               
-------------------------------+--------------------------------------------

Comment (by 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

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/7344#comment:1>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.