On 23 April 2015 at 22:28, Vladimir Prus
On 04/23/2015 10:02 PM, mloskot wrote:
Klaim - Joël Lamotte wrote
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev wrote:
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
Even with that, having no way for tools (like CMake) to identify one version from the other is problematic when you actually need to support both. Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
I second that too. As a user of CMake+Boost tandem, I find the issue a PITA indeed.
Is this problem unique to Boost?
I don't know.
Does any other library encode 32 vs 64 bit variant in library name?
I don't know.
I might not know lot about Windows development, but often library names does not encode anything really, and there are separate "Program Options" for 32-bit and 64-bit. And on Linux, 32-bit and 64-bit is also in different places, with library names being the same.
I guess, your observation is valid.
So why is Boost special?
My complain is more about CMake module FindBoost.cmake. I'm surprised it doesn't handle not uncommon scenario of building Boost-based programon 64-bit Unix host but targetting 32-bit architecture. I posted about it to CMake ml: http://public.kitware.com/pipermail/cmake/2015-April/060429.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net