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

Subject: Re: [Boost-maint] [context, config] Always setting address-model and architecture (Was: [boost] Conflicts when building libraries at root)
From: Jürgen Hunold (jhunold_at_[hidden])
Date: 2015-02-18 10:26:30

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.

> - 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?

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.

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...

Yours,

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold  ! juergen.hunold_at_[hidden]
* voice: 0049 4257 300       ! Fährstraße 1
* fax  : [phone]       ! 31609 Balge/Sebbenhausen
* mobil: 0049 178 186 1566   ! Germany