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