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

Indeed.

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

Right.

        Stefan

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