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