|
|
Boost Interest : |
Subject: Re: [Boost-cmake] Building boost "with an uninstalled build" and linking to boost libs
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2010-03-24 14:22:16
Welcome to Boost world. I don't think the Boost-CMake guys have
tackled the use-case that you are using so I hate to say it, BUT you
may be "ahead of the curve" on this one. All I can tell you is what
setup works for me. Theoretically you can do what you are trying to
do. Practically there probably needs some work to be done on Boost-
CMake. I think you are going to run into issues with the names of the
boost targets: boost-filesystem-mt-shared and their actual library
names. I don't have any suggestions for this save one.
In your "master cmakelists.txt" file you might have to manually set
"BOOST_INCLUDE_DIR, BOOST_LIBRARY_DIR and BOOST_ROOT" and see if that
helps. My thought is that if you can coerce the build directory for
boost to mimic that from an actual installation then you have a
fighting chance of using Find_package(boost... ). Otherwise you will
probably have to trod along and make some changes to the boost-cmake
to make this work for your case. If you do get something working,
PLEASE let us (and maybe the actual CMake mailing like) know as there
are a few of us that will be going down this road sooner rather than
later.
What needs to happen (in my mind) in the boost-exports.cmake or
UseBoost.cmake case is that the normal cmake variables need to be
filled out so all you really need to do in your case is "include($
{BOOST_USE_FILE})" and you will get all the locations of all the
libraries. Maybe I am not doing something correct with that. Qt does
something like this and it seems to work well. Again, maybe asking on
the actual CMake mailing list will bring more answers from those more
intimate with CMake.
___________________________________________________________
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jackson_at_[hidden]
BlueQuartz Software Dayton, Ohio
On Mar 24, 2010, at 1:50 PM, Brian Davis wrote:
> >> 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:
>
> -snip-
>
> SET( THIRD_PARTY_PACKAGES
> vtk-5.4.2
> VTKEdge-5-4-0
> dcmtk-3.5.4
> # boost-cmake-1_41_0
> )
>
> SET( VTK_DEFINES
> -DVTKEdge_USE_CUDA=YES
> -DVTKEdge_USE_DIRECTX=YES
> -DVTKEdge_BUILD_EXAMPLES=YES
> -DBUILD_SHARED_LIBS=YES
> -DVTK_DIR=${INSTALL_PREFIX}
> -DBUILD_SHARED_LIBS=YES
> -DCUDA_TOOLKIT_ROOT_DIR=${CUDA_TOOLKIT_ROOT_DIR}
> -DCUDA_SDK_ROOT_DIR=${CUDA_SDK_ROOT_DIR}
> # -DCUDA_CUTIL_INCLUDE_DIR=${CUDA_CUTIL_INCLUDE_DIR}
> -DCUDA_CUTIL_LIBRARY=${CUDA_CUTIL_LIBRARY}
> # -DCUDA_LIBRARIES=${CUDA_LIBRARIES}
> )
>
>
> foreach( PACKAGE ${THIRD_PARTY_PACKAGES} )
>
> ExternalProject_Add(
> ${PACKAGE}
> DOWNLOAD_COMMAND ""
> SOURCE_DIR ${TOP}/source/cpp/lib/3rdParty/Win/${PACKAGE}
> BINARY_DIR ${BUILD_DIR}/ouput/bin/${PACKAGE}
> INSTALL_DIR ${INSTALL_PREFIX}
> CMAKE_ARGS -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX} -
> DINSTALL_PREFIX=${INSTALL_PREFIX}
> ${VTK_DEFINES}
> )
>
> -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 boost.build 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:
>
> SET( BUILD_PROJECTS thread filesystem CACHE STRING "" FORCE )
>
> 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 mailing list
> Boost-cmake_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-cmake