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

Subject: Re: [boost] Encoding address-model in library names
From: Peter Dimov (lists_at_[hidden])
Date: 2017-07-05 21:43:06

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.

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

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