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