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

On 6 July 2017 at 00:04, Stefan Seefeld via Boost <boost_at_[hidden]>
wrote:

> 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).
>
>
This is not really what is happening. There is indeed a slow migration
toward 64bit
for a big number of applications
but it's not all applications that benefiting from it and there are reasons
to keep 32bit
as an alternative, either because you want benefits from 32bit arch (memory
consumption,
sometime speed, sometime binary size) or you need to allow your client
to chose themself which version si best for their use case.
In any way, having a default authoritative way to identify the Boost
binaries
helps a lot when you are in these cases, as the build tools can finally
select them for linking without having to make assumptions and without
forcing you to always specify a specific directory where the right library
binaries are.

>
> >> 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.
>
>
It would prevent tools to have a default way to find the correct libaries
as they
cannot assume that your build or distribution chose to use that supposed
additional flag
to make sur the names were augmented.

> Have any alternatives been considered ? What about changing the
> installation path for library files ? (this is how Linux deals with
> "multi-libs".)
>
>
I think that as long as there is a default authoritative organistion
to identify the libraries, it's enough to help with the problems from
missing them.
However, I remember some discussions in the past about a potential solution
where, if my memory is correct, considering the alternatives, the majority
prefered to have the info in the file names. My memory is a bit blurry on
that particular discussion, and it was at least a year ago, so I may be
wrong.

> >> 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
>
>
Joël Lamotte