On Thu, Apr 23, 2015 at 10:28 PM, 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 <
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?
In my current projects dependencies yes, but it's the same problem for any library that use the same path and filename for the output of compilation whatever the target architecture. As pointed by Andrey, most other libraries (including all the dependencies I use in all my projects except boost) will just use a different filename or directory path for the compilation output depending on the architecture (and build mode). They also distribute binaries with the same path organisation as the initial output (without moving files around) so that tools that easily identify right the binaries using their location.
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.
First, Program Files is supposed to be for installed programs or libraries. Most development work do not end there because these directories have special meaning and access rights protections (starting with Vista). If like me you prefer to compile boost yourself to be able to quickfix when necessary (or other dev-related reasons) you do not put anything dev-related into Program Files. (note that most devs on windows will have a directory for development which is never in Program Files, most of the time in either user directory or close to the root directory of the disk to avoid too long path issues that can happen on windows when generating files in deep directory hierarchies) Most other libraries providing binaries as said before will provide different paths for different modes/arch in the same binary package so that the user have one location with both binaries and sources/headers, like a freshly compiled version. Having only one location to look for both binaries also helps tools. At the moment, CMake FindBoost.cmake module will use the (unique) BOOST_DIR environment variable to guess the boost directory location, or ask the user if there is none provided. Once found, CMake cannot guess if it's 64 or 32 bits because nothing from boost conventions says so, so the user either have to specify which binaries to use separately using Boost_LIBRARYDIR or get link-time errors (very too late) when the CMake module finds a 64bit boost but the user is compiling a 32bit project (CMake, again, have no way to know that boost binaries were 64bit). Also, on linux, if you build your own boost (because fixes or something else), don't you NOT install it into the linux library dirs? I thought you would do it only for distributed versions of libraries.
So why is Boost special?
Boost don't have a way to identify if the binaries are 64 or 32bits. That's really the core root of the problem and would easily be fixed with any convention. Location don't help if the build system of the library don't enforce that location convention, so that tool knows where is what. As soon as it is provided, it will be easy to fix the CMake module or any tool that try to identify from a boost install. I also gave other details on the issue in the trac ticket https://svn.boost.org/trac/boost/ticket/10141
-- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost