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/