Subject: Re: [boost] Encoding address-model in library names
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-07-05 23:04:08
On 05.07.2017 18:52, Peter Dimov via Boost wrote:
> Stefan Seefeld wrote:
>> On 05.07.2017 18:22, Peter Dimov via Boost wrote:
>> > Stefan Seefeld wrote:
>> >> Why not build separate 32-bit and 64-bit installers, as lots of
>> other >> applications do ?
>> > Why does this matter?
>> Because they could use distinct installation prefixes to avoid
> By the same logic, you could use distinct installation prefixes for
> debug/release. One of these does not even need an installer.
> Also, you could use distinct installation prefixes for different
> toolsets, or for different Boost releases.
> As I said, if you don't use --layout=versioned, this change would seem
> inexplicable. If you do, it's a straightforward extension, we just
> encode one more property in the name, one that should have been added
> in 2005.
Fair enough. But it's a change, and as such, it comes at a price. (And
we haven't even talked about Andrey's comment:
> Does it only include the address model without the architecture? If
> yes, it doesn't really solve the problem since you'll still have the
> same issue when you compile 32-bit x86 and ARM binaries, for example.
> If we want to put binaries to the same directory, I think the name
> should include the architecture.
We should at least follow the naming conventions used by other
libraries, using suffixes such as 'x86' and 'x86_64' or somesuch. Just
adding a '-32' and '-64' suffix isn't good enough. Or we'll have to
change things again in the next release.
> As I also said, if you don't use --layout=versioned, you're unaffected.
> (I've conservatively left --layout=tagged unchanged, because I'm not
> familiar with its real-world uses.)
-- ...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