Re: [boost] Encoding address-model in library names

Subject: Re: [boost] Encoding address-model in library names
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2017-07-05 23:37:01

On 5 July 2017 at 23:43, Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Stefan Seefeld wrote:
>
>> On 05.07.2017 17:16, Peter Dimov via Boost wrote:
>> > I have prepared the pull requests necessary to encode the address-model
>> > (32 or 64) in the library names, which allows placing the 32/64 >
>> libraries into the same stage/install directory, and building with >
>> address-model=32,64 in one go.
>>
>
> ...
>
> What problem is this supposed to solve ?
>>
>
> The same problem solved by encoding all other properties into the library
> names, such as the variant (debug/release), the runtime-link
> (static/shared), the Boost version, and so on.
>
> How frequently do users need both address-models on the same deployment
>> platform (and in the same path) ?
>>
>
> Those users that develop or maintain software under both address models
> do. Others don't. If you fall into the latter camp, you wouldn't understand
> the need for this change and would consider it unnecessary.
>
>
Yes, it made discussions around this change request very difficult as not
everyone is in situations where not having this kind of naming is
problematic.

> Specifically, is this an optional change, or a compulsory one ?
>>
>
> It's not clear how this could be an "optional" change. When you issue the
> command "b2 install", the libraries have to be named somehow.
>
> Would the change mean that all boost libraries would henceforth contain
>> the address-model in their names, and thus that all boost users would have
>> to adjust their own build instructions ?
>>
>
> Yes, if they use --layout=versioned, which is the default on Windows. No,
> if they don't, which is the default on Linux.
>
>
Seems like a good default to me.

> Furthermore, my answer to the last question depends on whether this is an
>> optional feature or a compulsory change. In case of the latter, I'm against
>> the change.
>>
>
> Special-casing Boost.Python to not support this feature would be a hassle
> and a bit hostile to its users, relegating them to a second class, but it's
> doable.
>
>
Joël Lamotte