On 6/07/2017 10:00, Andrey Semashev wrote:
On 07/06/17 00:16, Peter Dimov 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. [...]
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.
I guess the question there is how often people build multi-architecture. On Windows, I see it as relatively common to build both 32-bit and 64-bit applications and libraries. More importantly, there is an installation scenario where an application suite might contain a mixture of 32-bit and 64-bit applications, where it would be convenient to have all the dependent libraries (including Boost) in the same directory, since Windows has a convention of looking in the same directory as the original application for its library dependencies, and you have to jump through a lot of hoops to make it do differently. On the other hand, at runtime you'd never have x86 and ARM libraries in the same folder. At build time it's trivial enough to have your x86/64 libraries in one folder and your arm libraries in another; it might be convenient to have them in one place but I don't see this as compelling (but then I don't build arm binaries as a matter of course, so take that with a grain of salt). So on Windows, there would be a large benefit to discriminating between 32-bit and 64-bit, and little-to-no benefit to discriminating between architectures. On Linux, it's a moot point, since Linux: (a) doesn't use the versioned file naming layout, so this change doesn't affect them in the first place (b) does have a convention of storing (and looking for) library binaries in architecture+model specific folders rather than in the same folder As for the change itself, I welcome it -- it's not hard to work around the current behaviour (https://stackoverflow.com/a/42408982/43534) but it would be nice not to have to. For most Windows users it shouldn't adversely affect builds (thanks to auto linking) but install packages and the like would probably need to be tweaked for filename changes. While this might annoy some people, as long as it's infrequent and valuable enough (as this seems to be) it should be fine.