Am Mittwoch, 18. Februar 2015, 18:58:01 schrieb Vladimir Prus:
On 02/18/2015 05:55 PM, Jürgen Hunold wrote:
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.
+1 for this plan. And it would be cool if 3 enables me to use "feature.set-default address-model : 64" on Windows 64 bit machines to enforce 64 bit builds as default. Or maybe just auto-detect it...
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.
I just wanted to mention it. I've tried this way but it quickly gets dirty as soon as one gets both "header-only" and library. So -2 for this solution. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany