|
Boost : |
Subject: Re: [boost] Encoding address-model in library names
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-05 21:30:05
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.
Vinnie Falco originally wrote:
> I'd like to avoid a lengthy debate, and if no one wants to do it just
> provide me with working code for accomplishing it and I'll submit a
> pull request.
Given how intrusive a change that is, I'd like to understand a bit
better what change he had in mind precisely, and what the effect of the
below PRs are.
Specifically, is this an optional change, or a compulsory one ? 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 ?
What problem is this supposed to solve ? How frequently do users need
both address-models on the same deployment platform (and in the same path) ?
> These are
>
> https://github.com/boostorg/boost/pull/147
>
> and
>
> https://github.com/boostorg/config/pull/159
>
> This being a Serious Change, the prudent thing to do is to wait out
> 1.65, then proceed.
>
> On the other hand, experience shows that this kind of change is only
> tested when a release goes out anyway; delaying it for four more
> months would not help much.
>
> Therefore, I'm calling for opinions; would people want this to go into
> 1.65? Into 1.66? Not at all?
I really don't think a change of that nature should go in without
discussion. 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.
Stefan
-- ...ich hab' noch einen Koffer in Berlin...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk