On Thursday 23 April 2015 23:28:54 Vladimir Prus wrote:
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 <
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? Does any other library encode 32 vs 64 bit variant in library name?
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.
So why is Boost special?
Boost is not special. Basically, every project deals with it in its own way on Windows (or just doesn't). The problem is that in Windows infrastructure there is no canonical library layout for different architectures, and Boost doesn't offer its own layout. This means CMake devs can't put anything sensible in Boost library lookup routines so that it at least sometimes work. I think most projects simply put the built binaries in different directories, and that's probably what Boost should do. I'd say the name of the directory should describe the target platform, something similar to what 'dpkg- architecture -qDEB_BUILD_GNU_TYPE' provides.