Subject: Re: [boost] [log] custom architecture and address-model
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2015-02-19 05:34:02
On 02/19/2015 12:31 PM, Andrey Semashev wrote:
> On Thu, Feb 19, 2015 at 11:59 AM, Vladimir Prus
> <vladimir_at_[hidden]> wrote:
>> 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?
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) ] ;
return <log-address-model>$(address_model) ;
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?
-- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk