2015-02-19 11:35 GMT+01:00 Vladimir Prus :

segmented-stacks sound like it's setting some implementation detail of Boost.Context? If so, having it as local property is fairly reasonable.

property segmented-stacks=on sets compiler flags -fsplit-stack and BOOST_USE_SEGMENTED_STACKS as well as linker flags -static-libgcc -> used to enable stacks which grow on demand

What does 'valgrind' property do? I actually can't find it.

property valgrind defines BOOST_USE_VALGRIND -> used in struct stack_context to enable memory leak detection (valgrind doesn't play weel with side-stacks, generated/used by boost.context, if it gets no hint)

On 02/19/2015 12:31 PM, Andrey Semashev wrote:

On Thu, Feb 19, 2015 at 11:59 AM, Vladimir Prus wrote:

...

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?

The custom features are needed to enable specific compiler options and source files when building the library. They need not be Boost.Log-specific, but I could not find any other way to achieve what I wanted. Please, do not remove these features with haste.

Could you explain what is the problem with these features and what is the proposed fix?

Andrey, the primary problem is that of code duplication. You have this: rule deduce-address-model ( properties * ) { local address_model = [ feature.get-values "address-model" : $(properties) ] ; if $(address_model) { return <log-address-model>$(address_model) ; } else { if [ configure.builds /boost/architecture//32 : $(properties) : 32-bit ] { return <log-address-model>32 ; } else if [ configure.builds /boost/architecture//64 : $(properties) : 64-bit ] { return <log-address-model>64 ; } } } and this is exactly equivalent to what libs/context/build/architecture.jam has, and which I'm moving to top level - except that is uses <log-address-model>, and not <address-model>. Code duplication is obviously bad, and having two features, address-model and log-address-model, seems also confusing. Would there be any reason for log-address-model and the if address-model is automatically set? Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com