View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015551CMakeCMakepublic2015-05-01 13:582016-06-10 14:31
ReporterZack Snyder 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformWindowsOSWindowsOS Version8.1
Product VersionCMake 3.2.2 
Target VersionFixed in Version 
Summary0015551: Boost libraries (.dll & .lib) should be found automatically inside the specified BOOST_ROOT directory
DescriptionThe boost binaries are not found when they are located under a certain sub directory in BOOST_ROOT.

I downloaded the prebuild boost binaries from: http://sourceforge.net/projects/boost/files/boost-binaries/ [^]
That will install the boost headers and libraries within one folder.
The folder of the binaries is called e.g. "lib32-msvc-12.0" or "lib64-msvc-12.0"
These folders are located under the BOOST_ROOT directory.

Finding boost within cmake will not work for the binaries, i.e.:
find_package(Boost COMPONENTS chrono system)
this will result in an error.

The user has to specify the environment variable BOOST_LIBRARYDIR.
e.g. set BOOST_LIBRARYDIR=%BOOST_ROOT%/lib64-msvc-12.0
and of course for 32 bit another directory.

Request:
1)
Is it possible that CMake can automatically iterate through the directory of boost and find this libraries? Or maybe you can add support to look after a directory called "lib64-*" or "lib32-*" and look into those.
2)
It should be also automatically found the correct binaries architecture for the currently used compiler, e.g. 32bit binaries for 32 compiler, etc...
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0038676)
Brad King (manager)
2015-05-01 14:07

 FindBoost will have to be taught about this binary distribution layout.

Currently the module has no maintainer:

 http://www.cmake.org/Wiki/CMake:Module_Maintainers [^]

If anyone wants to work on this, the relevant code is here:

 http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindBoost.cmake;hb=v3.2.2#l859 [^]

One could use CMAKE_SIZEOF_VOID_P to decide whether look for the lib32 or lib64 variant.
(0038715)
Zack Snyder (reporter)
2015-05-04 16:11

 The problem is bigger then I thought. There can be also a sub directory named "lib32-msvc-11.0" which might match the architecture, but not the compiler version.

What is the general cmake approach here?

It can be simply implement to look, depending on the architecture and the compiler for a certain sub directory. But then after a new compiler will be released, the cmake file needs to be updated...otherwise already running script might not work with newer compilers.
(0038716)
Brad King (manager)
2015-05-04 16:25

 Re 0015551:0038715: The future versions may be predictable. One could compute the directory name based on the current architecture and VS version (see CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION) rather than memorizing a table.
(0042771)
Kitware Robot (administrator)
2016-06-10 14:29

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2015-05-01 13:58 Zack Snyder New Issue
2015-05-01 14:07 Brad King Note Added: 0038676
2015-05-04 16:11 Zack Snyder Note Added: 0038715
2015-05-04 16:25 Brad King Note Added: 0038716
2016-06-10 14:29 Kitware Robot Note Added: 0042771
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team