Boost logo

Boost Interest :

Subject: Re: [Boost-cmake] Building boost "with an uninstalled build" and linking to boost libs
From: Brian Davis (bitminer_at_[hidden])
Date: 2010-03-24 13:50:34

>> I still remain "old" school. I build* boost and install it somewhere. I
then use the following in my CMakeLists.txt file.

I am trying (in vain) to build only the parts of boost I need. Also is an
interesting chicken-and-the-egg problem with FindBoost or really find
whatever in CMake if doing a check out and build without boost installed
i.e. the CMakeLists.txt file specifies the build of boost. Using
find_package( boost .. whatever) will fail in a project if that project
contains (like mine) ExternalProject_Add such as below example:


# boost-cmake-1_41_0



        SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
        BINARY_DIR ${BUILD_DIR}/ouput/bin/${PACKAGE}

-end snip-

>> * I build boost with CMake most of the time. There are some CMake
variables that you need to set to correct create an installation that mimics
the installation, which FindBoost.cmake REQUIRES to successfully
find boost.

I have found that CMake has a really difficult time finding Boost if it is
not build and installed yet. Decent depenecny checking in CMake and a
overhaul of add_subdirecotyr and ExternalProject_Add might solve this
problem not to mention laying down some ground rules for third party lib
developers that would allow a solution to this issue.

Also I tralied off in my email above with " Let me be clear ..." as I guess
I walked a way and did not finish my thought, came back and pushed send...
so I guess I was definitely not clear. What I meant to say was that *in my
opinion* this is a problem with CMake. Not the boost implementation of the
boost build in CMake refering to CMakes inability to handle third party
libraries and build only what is needed through target dependency
specification, and a means to do this with clobbering global project
settings when using add_subdirectory and variable names such as
BUILD_LIBRARIES. For instance if another third party library used this
variable name for different purposes and I used add_subdirectory on both
boost and this other said 3rdParty lib all kinds of good fun would ensue. I
thought as time went on things were supposed to get better not worse
(referring to build systems). Also I have noticed in VTKEdge and other
libs that they include FindCUDA and other FindWhatevers likely due to these
not being included in CMake 2.6 (a guess on my part). Now comes the problem
if using 2.8 or newer version (when one is released) which would be
preferred the one in the 3rdParty library tree or the one in CMake release?
Turns out my experience to this problem was that when using 2.8 and VTK
build and ExternalProject_Add as above the FindCUDA in the VTKEdge source
will be used not the installed CMake Version.

>> The issue that I had (raised on this mailing list) with the exports (at
the time) was that you needed to know the exact way boost was built
(boost-filesystem-mt-shared) which was different on each of my systems.
Using an actual installed boost and letting FindBoost.cmake do its job gave
me better results. Your mileage may vary.

Then you should really love this one: When using:


I end up with thread as a real project in Visual Sudio and a phantom project
(no source) for filesystem. There is no boost_filesystem_mt-shared or mt
shared-debug and there are the corresponding entries for thread in
Exports.cmake, but no entry for filesystem... awesome.

Brian J. Davis

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at