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:
>> After further investigation, it seems to be a bug. I created a ticket for it:
>> 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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk