Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)

Subject: Re: [boost] [Boost-maint] [context, config] Always setting address-model and architecture (Was: Conflicts when building libraries at root)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2015-02-18 10:58:01

On 02/18/2015 05:55 PM, Jürgen Hunold wrote:
> Hi Volodya,
>
> Am Mittwoch, 18. Februar 2015, 14:28:48 schrieb Vladimir Prus:
>> On 01/05/2015 10:37 PM, Jürgen Hunold wrote:
>>>
>>> Unfortunately, we still have Boost.Context open.
>>
>> Okay, so the problem we're facing is that building master results in:
>>
>> 	error: Tried to build the target twice, with property sets having
>> 	error: these incompatible properties:
>> 	error:
>> 	error:     -  none
>> 	error:     -  <address-model>32 <architecture>x86
>>
>> What happens is this:
>>
>> - Context library is built
>> - It detects default address model and architecture of the current
>> toolchain, and adds those to requirements
>> - Since there's a global dependency on 'headers' target, this pretty much
>> immediately rebuilds everything with new address-model and architecture
>> properties.
>
> Not correct: Boost.Context needs Boost.System so it requires a build with
> those properties. As they have currently have no defaults, the explicit values
> differ from the implizit default (none) for both.

Well, it my brief check, it was the headers->system path that first requested
system with address-model=32. Anyway, it does not matter for the rest of this
discussion.

>> - We get property set clash
>
> Correct.
>
>> One way to solve this is to restructure Boost.Context setup so that added
>> properties do not escape. It's doable, but probably will be fragile.
>
> No doubt.
>
>> Another way is to take libs/context/config, move it to libs/config, and make
>> sure these properties are applied globally. That seems preferable. John,
>> any objections?
>
> I thought the correct way would be to move the architecture detection upwards?

That's roughly what I propose, too - but there are few further tweaks and options.

> We would need something along those lines (from context/bulld/Jamfile.v2)
>
> alias select_asm_context_sources
>    : asm_context_sources
>    : [ architecture.architecture ]
>      [ architecture.address-model ]
>    ;
>
> in boostcpp.jam in order to detect the architecture everywhere. It would then
> be helpfull to have sensible default values in order to shorten the generated
> paths for those defaults.

Right, so steps would be:

1. Move actual tests into config (we do need to have a few cpp files)
2. Move architecture.jam into either Boost.Build or boostcpp.jam
3. Make sure we don't generate extra path elements for default address model
4. Introduce a way to do these tests without requiring a bunch of .cpp files -
    sure Boost.Build can generate them on the fly.
5. Make these checks be automatic for all projects.

It seems that 1-2 should solve the immediate problem, and 1-3 should be pretty
good, although going all the way to 5 would be cool.

> Another solution would be to generate a "header-only" variant of Boost.System
> and use this nearly everywhere. This would solve *lots* of dependency
> problems...

Not sure I have an opinion on that.

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software/