19 Feb
2015
19 Feb
'15
9:16 a.m.
2015-02-19 9:59 GMT+01:00 Vladimir Prus
Hi,
it seems that Boost.Log defines, and checks, it's own log-address-model and log-architecture and log-instruction-set properties. Naturally, if I'm trying to make regular address-model and architecture properties always set, these are getting in the way.
Do we really need per-library properties? If a user wants to build Boost.Log with a particular architecture, I would think he can do:
./b2 --with-log <whatever>
If so, is everybody fine if I eliminate these custom features eventually?
boost.context has custom features: segmented-stacks and valgrind (context/build/Jamfile.v2) could you migrate those properties as 'main-line'/'regular' properties too (including always set)?