I am having more trouble than I'd expect getting CMake to find the sqlite3.dll library on Windows 7 (64-bit if that matters). I have downloaded and placed the latest sqlite3.dll and sqlite3.def files to C:\Windows\System32. I am using the FindSqlite3.cmake module below:
IF( SQLITE3_INCLUDE_DIR AND SQLITE3_LIBRARY_RELEASE AND SQLITE3_LIBRARY_DEBUG )
SET(SQLITE3_FIND_QUIETLY TRUE)
ENDIF( SQLITE3_INCLUDE_DIR AND SQLITE3_LIBRARY_RELEASE AND SQLITE3_LIBRARY_DEBUG )
FIND_PATH( SQLITE3_INCLUDE_DIR sqlite3.h )
FIND_LIBRARY(SQLITE3_LIBRARY_RELEASE NAMES sqlite3 )
FIND_LIBRARY(SQLITE3_LIBRARY_DEBUG NAMES sqlite3 sqlite3d HINTS /usr/lib/debug/usr/lib/ C:/Windows/System32/ )
IF( SQLITE3_LIBRARY_RELEASE OR SQLITE3_LIBRARY_DEBUG AND SQLITE3_INCLUDE_DIR )
SET( SQLITE3_FOUND TRUE )
ENDIF( SQLITE3_LIBRARY_RELEASE OR SQLITE3_LIBRARY_DEBUG AND SQLITE3_INCLUDE_DIR )
IF( SQLITE3_LIBRARY_DEBUG AND SQLITE3_LIBRARY_RELEASE )
# if the generator supports configuration types then set
# optimized and debug libraries, or if the CMAKE_BUILD_TYPE has a value
IF( CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE )
SET( SQLITE3_LIBRARIES optimized ${SQLITE3_LIBRARY_RELEASE} debug ${SQLITE3_LIBRARY_DEBUG} )
ELSE( CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE )
# if there are no configuration types and CMAKE_BUILD_TYPE has no value
# then just use the release libraries
SET( SQLITE3_LIBRARIES ${SQLITE3_LIBRARY_RELEASE} )
ENDIF( CMAKE_CONFIGURATION_TYPES OR CMAKE_BUILD_TYPE )
ELSEIF( SQLITE3_LIBRARY_RELEASE )
SET( SQLITE3_LIBRARIES ${SQLITE3_LIBRARY_RELEASE} )
ELSE( SQLITE3_LIBRARY_DEBUG AND SQLITE3_LIBRARY_RELEASE )
SET( SQLITE3_LIBRARIES ${SQLITE3_LIBRARY_DEBUG} )
ENDIF( SQLITE3_LIBRARY_DEBUG AND SQLITE3_LIBRARY_RELEASE )
IF( SQLITE3_FOUND )
IF( NOT SQLITE3_FIND_QUIETLY )
MESSAGE( STATUS "Found Sqlite3 header file in ${SQLITE3_INCLUDE_DIR}")
MESSAGE( STATUS "Found Sqlite3 libraries: ${SQLITE3_LIBRARIES}")
ENDIF( NOT SQLITE3_FIND_QUIETLY )
ELSE(SQLITE3_FOUND)
IF( SQLITE3_FIND_REQUIRED)
MESSAGE( FATAL_ERROR "Could not find Sqlite3" )
ELSE( SQLITE3_FIND_REQUIRED)
MESSAGE( STATUS "Optional package Sqlite3 was not found" )
ENDIF( SQLITE3_FIND_REQUIRED)
ENDIF(SQLITE3_FOUND)
This works fine on Linux, but not on Windows. I have spent a few hours now attempting small changes to other CMAKE variables with no luck. It seems like it should be straight forward getting CMake to find this dll. Could I get some help getting this to find the sqlite3 library on Windows?
There are some issues here and also some weird Windows stuff!
First issue; when searching for a library on Windows with MSVC as the generator, CMake will always look for a ".lib" file - never a ".dll", even if you specify e.g. sqlite3.dll as the NAMES argument to find_library. This is unfortunately not properly documented, in fact the docs for CMAKE_FIND_LIBRARY_SUFFIXES wrongly state:
This specifies what suffixes to add to library names when the find_library command looks for libraries. On Windows systems this is typically .lib and .dll, meaning that when trying to find the foo library it will look for foo.dll etc.
You can easily check this; simply add
message("CMAKE_FIND_LIBRARY_SUFFIXES: ${CMAKE_FIND_LIBRARY_SUFFIXES}")
to your CMakeLists.txt. You should see output like:
CMAKE_FIND_LIBRARY_SUFFIXES: .lib
This thread from the CMake mailing list further confirms this behaviour. If you really need to find the dlls, you'll need to use the find_file command, e.g:
find_file(SQLITE3_DLL_DEBUG NAMES sqlite3d.dll PATHS ...)
The next issue is a minor one. You should prefer PATHS to HINTS as the argument in find_xxx commands if it's a hard-coded guess. From the docs for find_library:
3. Search the paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option.
A slightly more serious issue is in the line:
FIND_LIBRARY(SQLITE3_LIBRARY_DEBUG NAMES sqlite3 sqlite3d ...)
You should specify sqlite3d first then sqlite3 or sqlite3 will incorrectly be chosen as the Debug library if both are available.
And now the weirdness...
On a Windows x64 system, the find_xxx partially ignores the C:\Windows\System32 directory in favour of the C:\Windows\SysWOW64 one.
If you don't have the sqlite3.lib in C:\Windows\SysWOW64, then the find_library command will always fail, regardless of the PATHS argument.
However, if you do have C:\Windows\SysWOW64\sqlite3.lib, then any combination of C:/Windows/SysWOW64 and/or C:/Windows/System32 as the PATHS argument finds the library, but sets the full path to C:/Windows/System32/sqlite3.lib even if C:/Windows/System32/sqlite3.lib doesn't exist! This is obviously useless if the library isn't there; a linker error will result.
There is some further reading again from the CMake mailing list here.
Having said that, if you're linking, you'll be using the .lib files, not the .dlls, and System32 & SysWOW64 aren't really the place for .lib files.
I didn't find that cmake looks for .lib. pls.
please check the cmake file and findSqlite.cmake file inside cmake folder and check for paths it is looking for.
when I gave the full path to the "dll", it worked for me corresponding to the input variable mentioned in cmake file, and it might work for you too.
If your problem is not solved, notify me to edit the answer.
Related
I have multiple versions of OpenCV installed, and CMake is finding the wrong one. I have installed opencv and opencv3 using brew, and they exist in the following paths:
/usr/local/opt/opencv3
/usr/local/opt/opencv
My CMakeLists.txt looks like the following:
cmake_minimum_required(VERSION 2.8)
set(ENV{OpenCV_DIR} "/usr/local/opt/opencv3")
project(TestProject)
#OpenCV
find_package( OpenCV 3 REQUIRED )
include_directories( ${OpenCV_INCLUDE_DIRS} )
MESSAGE ( STATUS "Found OpenCV: ${OpenCV_VERSION}" )
MESSAGE ( STATUS "OpenCV_INCLUDE_DIRS= ${OpenCV_INCLUDE_DIRS}" )
MESSAGE ( STATUS "OpenCV_DIR= $ENV{OpenCV_DIR}" )
I am using OpenCV_DIR to point to the location of the OpenCV that I would like to use (in this example it's set immediately before just to be 100% certain that this variable points to the right place).
My output is this:
-- Found OpenCV: 3.0.0
-- OpenCV_INCLUDE_DIRS= /usr/local/include/opencv
-- OpenCV_DIR= /usr/local/opt/opencv3
So, it's finding the right version of OpenCV (3.0.0), but the include path is set to some other opencv, in this case /usr/local/include/opencv points to /usr/local/opt/opencv, which is the 2.4.8 version.
As a result, none of my programs find the right files to include! Does anyone know how to tell CMake which version to look for, if the OpenCV_DIR environment variable does not seem to work?
You can explicitly assign the path in find_package. For example,
find_package( OpenCV 3 REQUIRED PATHS "/usr/local/opt/opencv3" )
As indicated OP is using cMake V2.8. Therefore the following applies to include your desired directory.
#OpenCV
find_package( OpenCV 3 REQUIRED )
include_directories([BEFORE] "/usr/local/opt/opencv3") # your cv2 desired folder
# stated here.
The [BEFORE] argument informs cMake about this particular folder to use first rather than the other CV folder.
For cMake higher than v2.8 you should not use the include_directories but rather the following:
target_include_directories(test PRIVATE ${YOUR_DIRECTORY})
I have a very simple CMake script. Unfortunately, the project uses a *.pde file which is plain C++ or C code.
CMake is working with any file ending, but I get a compiler error, because GCC does not know how to handle it. How can I add a global file extension to GCC, so that the *.pde file is compiled as a usual *.cpp file?
The -x c++ foo.pde command is nice if I want to use the console, but for CMake it is (I think) not applicable.
cmake_minimum_required(VERSION 2.8)
project(RPiCopter)
SET( RPiCopter
absdevice
containers
device
exceptions
navigation
frame
vehicle
receiver
scheduler
tinycopter.pde
)
message( STATUS "Include ArduPilot library directories" )
foreach( DIR ${AP_List} ${AP_List_Linux} ${AP_Headers} )
include_directories( "../libraries/${DIR}" )
endforeach()
include_directories( zserge-jsmn )
# ***************************************
# Build the firmware
# ***************************************
add_subdirectory ( zserge-jsmn )
#set(CMAKE_CXX_FLAGS "-x c++ *.pde")
ADD_EXECUTABLE ( RPiCopter ${RPiCopter} )
target_link_libraries ( RPiCopter -Wl,--start-group ${AP_List} ${AP_List_Linux} jsmn -Wl,--end-group )
You should be able to use set_source_files_properties along with the LANGUAGE property to mark the file(s) as C++ sources:
set_source_files_properties(${TheFiles} PROPERTIES LANGUAGE CXX)
As #steveire pointed out in his own answer, this bug will require something like the following workaround:
set_source_files_properties(${TheFiles} PROPERTIES LANGUAGE CXX)
if(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
add_definitions("-x c++")
endif()
Normally you should be able to just extend CMAKE_CXX_SOURCE_FILE_EXTENSIONS. This would help, if you have a lot of files with unknown file extensions.
But this variable is not cached - as e.g. CMAKE_CXX_FLAGS is - so the following code in CMakeCXXCompiler.cmake.in will always overwrite/hide whatever you will set:
set(CMAKE_CXX_IGNORE_EXTENSIONS inl;h;hpp;HPP;H;o;O;obj;OBJ;def;DEF;rc;RC)
set(CMAKE_CXX_SOURCE_FILE_EXTENSIONS C;M;c++;cc;cpp;cxx;mm;CPP)
I consider this non-caching being a bug in CMake, but until this is going to be changed I searched for a workaround considering the following:
You normally don't want to change files in your CMake's installation
It won't have any effect if you change CMAKE_CXX_SOURCE_FILE_EXTENSIONS after project()/enable_language() (as discussed here).
I have successfully tested the following using one of the "hooks"/configuration variables inside CMakeCXXCompiler.cmake.in:
cmake_minimum_required(VERSION 2.8)
set(CMAKE_CXX_SYSROOT_FLAG_CODE "list(APPEND CMAKE_CXX_SOURCE_FILE_EXTENSIONS pde)")
project(RPiCopter CXX)
message("CMAKE_CXX_SOURCE_FILE_EXTENSIONS ${CMAKE_CXX_SOURCE_FILE_EXTENSIONS}")
add_executable(RPiCopter tinycopter.pde)
I decided to use this approach. I just remove the file ending by cmake in the temporary build directory.
So GCC is not confused anymore because of the strange Arduino *.pde file extension.
# Exchange the file ending of the Arduino project file
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/tinycopter.pde ${CMAKE_CURRENT_BINARY_DIR}/tinycopter.cpp)
CMake doesn't do this for you:
http://public.kitware.com/Bug/view.php?id=14516
I'm using CMake to generate solution for Visual Studio and Makefile for Windows. I have already succeeded to make different folder for debug and release types, and i found the two options in my solution.
Now i have 3 questions :
I want to do the same for win32 and x64 ? Is it possible ? EDIT : After some research, it's seem not possible ?)
And the another question, when i generate "NMake Makefiles" i can't retrieve my two types (release and debug) in my makefile ! In which files i can retrieve this ?
EDIT : And how can i set debug or release in CLI with NMake command ?
Here is my CMakeLists.txt :
cmake_minimum_required(VERSION 2.8)
# Configuration of Types
MESSAGE("Generated with config types: ${CMAKE_CONFIGURATION_TYPES}")
SET(CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "" FORCE)
#Configuration of zlib.lib
PROJECT(zlib C)
# Path of Release
SET(LIB_RELEASE_PATH "../cmake_x64")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE "${LIB_RELEASE_PATH}/lib/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_RELEASE "${LIB_RELEASE_PATH}/lib/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE "${LIB_RELEASE_PATH}/lib/" )
# Path of Debug
SET(LIB_DEBUG_PATH "../cmake_x64d")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG "${LIB_DEBUG_PATH}/lib/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_DEBUG "${LIB_DEBUG_PATH}/lib/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG "${LIB_DEBUG_PATH}/lib/" )
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} /W3")
ADD_DEFINITIONS("/Gm" -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_UNICODE)
# Files of librairy
ADD_LIBRARY(
zlib
STATIC
../.c
and
../.h
)
#Configuration of core.dll
project(core CXX)
# Path of Release
SET(BIN_RELEASE_PATH "../cmake_x64")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_RELEASE "${BIN_RELEASE_PATH}/bin/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_RELEASE "${BIN_RELEASE_PATH}/bin/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE "${BIN_RELEASE_PATH}/bin/" )
# Path of Debug
SET(BIN_DEBUG_PATH "../cmake_x64d")
SET( CMAKE_ARCHIVE_OUTPUT_DIRECTORY_DEBUG "${BIN_DEBUG_PATH}/bin/" )
SET( CMAKE_LIBRARY_OUTPUT_DIRECTORY_DEBUG "${BIN_DEBUG_PATH}/bin/" )
SET( CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG "${BIN_DEBUG_PATH}/bin/" )
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
set_property(GLOBAL PROPERTY LINK_LIBRARY_DEPENDENCIES "yes")
add_definitions(-D_UNICODE -D_USRDLL -DCORE_EXPORTS)
add_definitions("/Gm")
# Files of librairy
add_library(
core
SHARED
../.h
and
../.cpp
)
link_directories("/build/lib/")
target_link_libraries(core zlib)
#END OF FILE
Thanks
I don't know much about nmake or the cmake nmake generator, but if it's anything like the makefile generator then the answer to all three of your questions is "you can't".
For the first question, Visual Studio (to my understanding) doesn't support multiple architectures the way it supports build types; certainly the cmake-generated Visual Studio project files cannot do it.
For the second question, makefiles generated by cmake do not support build types, and I'm assuming nmake has the same limitation. I expect this is just a limitation in the cmake makefile generator; there's no inherent reason in makefiles that multiple build types couldn't be supported.
And similarly for the third question, since you cannot support multiple build types with makefile/nmake output you certainly cannot choose which one to build on the command line.
The answer to all these questions is, you have to re-run cmake with different flags to select different options (architecture and build type).
If what you're concerned about is not having to clean your workspace and reconfigure it from scratch each time and lose your previous work, then you should look into the out-of-source build feature of cmake. Basically, instead of using:
cmake .
you use something like:
mkdir obj-x86
cd obj-x86
cmake ..
mkdir ..\obj-x64
cd ..\obj-x64
cmake ..
You run cmake in a different directory (doesn't have to be a subdirectory) for each different configuration. They can all share the same source tree. Sometimes when you try this for the first time you'll discover issues in your cmake files where they're assuming a particular working directory, etc., and you may need to update them to use variables like CMAKE_SOURCE_DIR rather than relative paths.
I'm trying to build a static library to be released as an API for a network device. I can successfully compile and link the library to produce .lib output files, and I relocate them into a directory structure as follows:
EyeLib
L-Include
| L-PublicInterface.h
L-Lib
| L-debug
| | L-MyLib.lib
| | L-MyLib.pdb
| L-release
| L-MyLib.lib
L-MyLibConfig.cmake
Where the MyLibConfig.cmake file is extremely simple, and contains:
# the header file is relative to this cmake file, so get the path.
GET_FILENAME_COMPONENT( MyLib_TOPLEVEL_DIR ${CMAKE_CURRENT_LIST_FILE} PATH )
SET( MyLib_INCLUDE_DIR ${MyLib_TOPLEVEL_DIR}/include )
IF( WIN32 )
FIND_LIBRARY( MyLib_DEBUG_LIBRARY MyLib ${MyLib_TOPLEVEL_DIR}/lib/debug )
FIND_LIBRARY( MyLib_RELEASE_LIBRARY MyLib ${MyLib_TOPLEVEL_DIR}/lib/release )
SET( MyLib_LIBRARIES optimized ${MyLib_RELEASE_LIBRARY} debug ${MyLib_DEBUG_LIBRARY} )
ENDIF( WIN32 )
IF( UNIX )
FIND_LIBRARY( MyLib_LIBRARY MyLib ${MyLib_TOPLEVEL_DIR}/lib )
SET( MyLib_LIBRARIES "${MyLib_LIBRARY}" )
MARK_AS_ADVANCED( MyLib_LIBRARY )
ENDIF( UNIX )
# handle the QUIETLY and REQUIRED arguments
INCLUDE(FindPackageHandleStandardArgs)
FIND_PACKAGE_HANDLE_STANDARD_ARGS(MyLib DEFAULT_MSG MyLib_LIBRARIES MyLib_INCLUDE_DIR)
MARK_AS_ADVANCED( MyLib_INCLUDE_DIR )
This build structure has worked for some test libraries I've built in the past, but I'm getting a link error when I try and use it to build a simple test app saying "error LNK1104: cannot open file 'libboost_thread-vc110-mt-s-1_54.lib'"
I can get the test app to build and run successfully if I add it to the same project as the library build. I assume this is because the library build is finding the boost libs to link against, so it propagates through to the executables in the project.
I built boost 1.54 with b2 link=static runtime-link=static threading=multi variant=debug,release --layout=tagged and linked both the library build and the test app build to the static MSVC runtime (/MT).
Can anyone offer some help/advice/further tests with this one? I need to make sure that all the boost stuff is compiled-in to the API library, so our clients don't have to install boost themselves.
Additional Info
In-case it's helpful, here's the cmakelists.txt file from the library build:
set(LIBRARY_OUTPUT_PATH "${CMAKE_BINARY_DIR}/lib")
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
find_package(Boost REQUIRED COMPONENTS system date_time regex thread chrono)
if(NOT WIN32)
list(APPEND Boost_LIBRARIES pthread)
endif()
include_directories(${Boost_INCLUDE_DIRS})
FILE(GLOB srcs *.cpp)
FILE(GLOB headers *.h)
set(libname MyLib)
set(deps ${Boost_LIBRARIES})
#To allow compilation. std=c++0x is for accepting the access to enums, which usually is just accepted with Visual Studio
IF( NOT WIN32 )
set (CMAKE_CXX_FLAGS "-fpermissive -std=c++0x")
ENDIF( NOT WIN32 )
SOURCE_GROUP( ${libname} FILES ${srcs} )
SOURCE_GROUP( "${libname}\\Hdr" FILES ${headers} )
add_library(${libname} ${srcs} ${headers})
target_link_libraries( ${libname} ${deps} )
This is by design.
When building a static library, any dependencies to that library will not get linked into the library directly. Instead when building an executable all library dependencies (direct and indirect) will be linked directly to that executable.
This is also the way most compiler handle static libraries. While VS does offer a special option to link dependencies into static libs, this is not possible on e.g. gcc without resorting to dirty file hacks. Since CMake only supports features that can be used on all supported generators, CMake will not allow to do this even on VS builds.
You have a couple of options now:
Use a dll instead of a static library (add_library(${libname} SHARED ...)). While a static library is basically a bunch of object files wrapped together, a dll is more or less the same as an executable. In particular, all static library dependencies get linked directly into the dll. The disadvantage here is that you have to deal with the usual dll mess: You have to specify which functions to export and the usual issues with passing stuff across dll boundaries apply.
Have your find script also search for all the dependencies. You should be able to restructure your library's dependency handling in a way that the amount of code duplication is minimal. The disadvantage is that configuring a third-party application becomes more difficult (especially on Windows) since you now not only need to find the library itself, but also all of its dependencies.
Use exported targets. This approach makes most sense if the library is built on the same machine as the final executable. Upon building the library, CMake auto-generates the config files for using that library. Your application then just needs to find an include that script and you're good to go. Disadvantage is that the export mechanism is not the most straight-forward feature of CMake, so you will have to spend some time to familiarize yourself with it.
Pull in the library sources directly into each executable. Basically each executable does an add_subdirectory on the library source dir. You still have to configure the dependencies for each executable and on top of that you also have to build the library seperately for each executable. You probably don't want to do this.
I'm trying to use a CMake script to compile a Boost-based application on Windows.
The header-only libraries work fine, but CMake fails to find the libraries (the following Boost libraries could not be found: boost_serialization). The relevant part of the CMake script is:
# Path where CMake can find additional libraries
SET(CMAKE_PREFIX_PATH Libs)
# Boost
SET(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")
SET(Boost_USE_STATIC_LIBS ON)
find_package(Boost REQUIRED COMPONENTS serialization)
I have a folder called "Libs" inside my project where third-party libraries such as DevIL and Boost are stored, so I set this first. It works fine for Devil and Boost header-only stuff, so I assume I should not need the BOOST_ROOT variable.
The Boost installation is the standard source distribution from boost.org which I compiled with BJam. The libraries are stored in boost_1_47_0\bin.v2\libs, and I didn't change anything in the build process.
I think it is a bit odd, that the boost_1_47_0\libs folder doesn't contain any library files but BJam files and other stuff, but that shouldn't be a problem since this seems to be the normal way to build Boost on Windows from the source.
I looked at the Debug output from the FindBoost.cmake file (I'm using the default script from CMake 2.8) and it doesn't seem to look into bin.v2. Instead it searches boost_ROOT/lib, but when I copied the content from bin.v2\libs to lib it still didn't find anything.
So what is an elegant way to find Boost that will also work on other platforms with common Boost distributions?
I would try setting BOOST_ROOT inside your CMakeLists.txt file. I know that CMake 2.8.6 will find Boost 1.47.0 when you set the Boost_ADDITIONAL_VERSIONS variable since it works for me on Windows when I have BOOST_ROOT set.
Here is what I have in one project:
set( BOOST_COMPONENTS_NEEDED serialization )
# The following verifyies that BOOST_ROOT is set properly.
if(NOT BOOST_ROOT AND NOT $ENV{BOOST_ROOT} STREQUAL "")
FILE( TO_CMAKE_PATH $ENV{BOOST_ROOT} BOOST_ROOT )
if( NOT EXISTS ${BOOST_ROOT} )
MESSAGE( STATUS ${BOOST_ROOT} " does not exist. Checking if BOOST_ROOT was a quoted string.." )
STRING( REPLACE "\"" "" BOOST_ROOT ${BOOST_ROOT} )
if( EXISTS ${BOOST_ROOT} )
MESSAGE( STATUS "After removing the quotes " ${BOOST_ROOT} " was now found by CMake" )
endif( EXISTS ${BOOST_ROOT})
endif( NOT EXISTS ${BOOST_ROOT} )
# Save the BOOST_ROOT in the cache
if( NOT EXISTS ${BOOST_ROOT} )
MESSAGE( WARNING ${BOOST_ROOT} " does not exist." )
else(NOT EXISTS ${BOOST_ROOT})
SET (BOOST_ROOT ${BOOST_ROOT} CACHE STRING "Set the value of BOOST_ROOT to point to the root folder of your boost install." FORCE)
#SET (BOOST_INCLUDEDIR ${BOOST_ROOT}/Include)
#SET (BOOST_LIBRARYDIR ${BOOST_ROOT}/lib)
endif( NOT EXISTS ${BOOST_ROOT} )
endif(NOT BOOST_ROOT AND NOT $ENV{BOOST_ROOT} STREQUAL "")
if( WIN32 AND NOT BOOST_ROOT )
MESSAGE( WARNING "Please set the BOOST_ROOT environment variable." )
endif( WIN32 AND NOT BOOST_ROOT )
set(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")
set(Boost_DEBUG ON)
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
FIND_PACKAGE(Boost 1.47.0 COMPONENTS ${BOOST_COMPONENTS_NEEDED})
if(Boost_FOUND)
MESSAGE( STATUS "Setting up boost." )
include_directories(${Boost_INCLUDE_DIRS})
if(Boost_DEBUG)
MESSAGE( STATUS "BOOST Libraries " ${Boost_LIBRARIES} )
FOREACH(BOOST_COMPONENT ${BOOST_COMPONENTS_NEEDED})
STRING( TOUPPER ${BOOST_COMPONENT} BOOST_COMPONENT_UPCASE )
MESSAGE( STATUS "Boost " ${BOOST_COMPONENT} ": " ${Boost_${BOOST_COMPONENT_UPCASE}_LIBRARY} )
MESSAGE( STATUS "Boost " ${BOOST_COMPONENT} " Debug: " ${Boost_${BOOST_COMPONENT_UPCASE}_LIBRARY_DEBUG} )
MESSAGE( STATUS "Boost " ${BOOST_COMPONENT} " Release: " ${Boost_${BOOST_COMPONENT_UPCASE}_LIBRARY_RELEASE} )
ENDFOREACH(BOOST_COMPONENT)
endif(Boost_DEBUG)
endif(Boost_FOUND)
Well, I solved the problem, but I'm not fully satisfied with my solution.
In my opinion the problem was that BJam creates a too complex folder structure. Now I just copied the library files from "boost_1_47_0\bin.v2\libs\serialization\build\msvc-9.0\debug\link-static\threading-multi" to "boost_1_47_0\lib".
I have to do this by hand, but I'm not using that many Boost libraries, so this step is OK in my opinion. I will document my solution aside the CMake script, so other users should get along with that.
I've had a problem with this before. For some reason b2 (aka BJam) created the Boost libraries with a leading "lib".
The CMake script will not look for a file named libboost_thread.lib. It will only find boost_thread.lib. Remove the leading lib and CMake should find them.
I came here with a similar issue and just wanted to say my fix was similar, but not exactly the same.
My install prefix was C:\lib\boost\boost_1_57_0. I set a BOOST_ROOT environment variable pointing to that directory, but CMake (3.1.0) still couldn't find the headers. I realized the headers defaulted to install to C:\lib\boost\boost_1_57_0\include\boost-1_57\boost. I'm not going to run multiple versions so I just moved the final Boost directory down one and removed the boost-1_57 directory and ended up with headers here:
C:\lib\boost\boost_1_57_0\include\boost
And CMake found everything.
You can add the following option to the command line of CMake to tell CGAL to use the static Boost libraries:
-DCGAL_Boost_USE_STATIC_LIBS=true