Re: [Boost-build] Target OS preprocessor macro

Subject: Re: [Boost-build] Target OS preprocessor macro
From: Vladimir Prus (ghost_at_[hidden])
Date: 2012-09-20 15:07:36

On 13.09.2012 10:41, Jurko Gospodnetić wrote:
>    Hi.
>
>> 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?
>
>    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. :-)

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