Re: [boost] [log] custom architecture and address-model

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:
>>
>> 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