[log] custom architecture and address-model
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? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
2015-02-19 9:59 GMT+01:00 Vladimir Prus <vladimir@codesourcery.com>:
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)?
Hi Oliver, On 02/19/2015 12:16 PM, Oliver Kowalke wrote:
2015-02-19 9:59 GMT+01:00 Vladimir Prus <vladimir@codesourcery.com>:
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)?
segmented-stacks sound like it's setting some implementation detail of Boost.Context? If so, having it as local property is fairly reasonable. What does 'valgrind' property do? I actually can't find it. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
2015-02-19 11:35 GMT+01:00 Vladimir Prus <vladimir@codesourcery.com>:
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 Thu, Feb 19, 2015 at 11:59 AM, Vladimir Prus <vladimir@codesourcery.com> 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?
On 02/19/2015 12:31 PM, Andrey Semashev wrote:
On Thu, Feb 19, 2015 at 11:59 AM, Vladimir Prus <vladimir@codesourcery.com> 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
On Thu, Feb 19, 2015 at 1:34 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
On 02/19/2015 12:31 PM, Andrey Semashev wrote:
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:
[snip]
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.
Totally agree about duplication. It seems Boost.Log code is indeed the same as Boost.Context.
Would there be any reason for log-address-model and the if address-model is automatically set?
If log-address-model is the same as the automatically set one, there is no reason to keep it. Could you prepare a pull request please? Thanks.
participants (3)
-
Andrey Semashev -
Oliver Kowalke -
Vladimir Prus