Re: [Boost-build] Suppressing auto-detected address-model from paths

Subject: Re: [Boost-build] Suppressing auto-detected address-model from paths
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-04-04 07:19:07

On 04/04/2015 12:19 AM, Steven Watanabe wrote:
> AMDG
>
> On 04/03/2015 01:48 PM, Vladimir Prus wrote:
>>
>> So the attached patch implements a stop-gap approach. It adds a new
>> composite property
>> representing deduced address model as well as 'hidden' attribute for
>> features. So, if we have
>>
>>      <deduced-address-model>64 <address-model>64
>>
>> then the latter is consumed by the former, and the former is hidden from
>> the path. If we have
>> <snip>
>> Comments? Is it good for
>> upcoming release?
>>
>
> <deduced-address-model> should not depend on
> a user specified <address-model>.  It should
> only depend on the compiler default.

Yes, I woke up with exactly same conclusion today. With the original patch, explicitly specifying
address-model=64 on the command line will add a path element even if compiler default is also 64-bit.

The attached boost.diff handles it. However, it requires a further change to build, also attached.
Right now, when indirect conditional returns a composite property, its constituents override any
existing properties. In case of deduce-address-model, we want it to be expanded, but not override
any value of address-model that is already specified.

In future, we'll probably have custom code to select toolchain and then determine these
properties, but for now, the only way I could think of was to change expansion of result
of indirect conditional to do what we want for address-model. It's quite possible
than existing code will be affected, but it will be easy to fix via explicit feature.expand
call. Comments?

-- 
Vladimir Prus
http://vladimirprus.com