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: - 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
> 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
>> - We get property set clash
>> 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
Not sure I have an opinion on that.
-- Vladimir Prus CodeSourcery / Mentor Embedded http://www.mentor.com/embedded-software/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk