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

Subject: Re: [boost] Encoding address-model in library names
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-05 22:04:50

On 05.07.2017 17:43, Peter Dimov via Boost 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.

That's too simplistic. I write portable software which I want to be able
to deploy on many different platforms. I also understand the need for
multiple build variants being hosted side-by-side. But while there has
been a time when it was common to run 32-bit and 64-bit applications on
the same machine, I believe this use-case is in sharp decline, as 64-bit
platforms are now the norm (and wherever 32-bit apps are run, it's the
only choice).

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

Of course. I would expect the `b2 install` to work just as before,
without any change. There could be a new command-line option (or even
feature) that indicates whether the address-model should be included in
the name (similar to the --layout parameter). Though I admit the implied
complexities, especially with auto-linking enabled, are substantial.
This is exactly why I'm questioning the usefulness of this whole idea.

Have any alternatives been considered ? What about changing the
installation path for library files ? (this is how Linux deals with
"multi-libs".)

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

I'm not talking about Boost.Python. You asked on the list what people
(developers and users, I suppose) thought, and so I replied. I
definitely do not want Boost.Python to be treated any different. My
opinion concerns all of Boost.

In a nutshell: this is clearly a change where we need to closely look at
the cost/benefit ratio. And since (without further data) this seems to
benefit only very few people, I think it's too high a price.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...