|
|
Boost Interest : |
Subject: [Boost-cmake] FindBoost.cmake
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-10-29 15:38:09
Michael Jackson wrote:
> So the problem I see with this is that I still need to know "a priori"
> what boost libraries are available on the system so exporting the
> targets really doesn't help much, at least not me.
> In your example (quoted below) what happens if I don't have the
> shared-debug of boost-thread but instead of static-debug?
> add_executable(my_program main.cpp) target_link_libraries(my_program
> boost_thread-mt-shared-debug)
>
> Currently I have something like:
>
> target_link_libraries(MyProgram ${Boost_THREAD_LIBRARY})
> That line will "do the right thing" depending if I compile in debug or
> release. The variable is based on what is found in the boost
> installation. We can all probably agree that the weakest part of
> FindBoost.cmake is the actual "finding" of the boost libraries based on
> all of the possible suffixes that are put on the libraries. If there was
> a UseBoost.cmake file, all the ${Boost_XXX_LIBRARY} would be filled in
> and no _searching_ would be required by FindBoost.cmake. At most someone
> might have to just set BOOST_ROOT as an environment variable or point
> cmake to where the UseBoost.cmake file is at.
> Debugging problems when "FindBoost.cmake" doesn't find boost is a
> PITA. I has happened to me more than a few times.
> Comments on my comments?
I agree completely... I stumbled on that EXPORT feature and found it
neat. The find_package still needs fixing. But the case where I just
want to build my stuff against a noninstalled tarball comes up a lot for
me, so I think this will come in handy, and you won't know it is there
if it doesnt.
On the FindBoost front (mostly questions for Brad):
Currently we work with cmake back to 2.6.4, I'd like to do something
that works independently of cmake's Modules/FindBoost.cmake (I'm frankly
afraid to even look inside that file). CMake will prefer that file
unless NO_MODULE is specified, so for users of cmake that precede our
upcoming FindBoost.cmake changes, the following will do the Right Thing
if a Boost.CMake-built boost is installed:
find_package(Boost 1.41.0 COMPONENTS signals NO_MODULE)
as the Config mode path search will be done for a BoostConfig.cmake and
BoostConfigVersion.cmake, and we win. I'm wondering:
- Could the FindBoost.cmake module be set up to first perform a Config
search, and then fall back to what it does now if that fails? e.g. I
have a 2.8.1 cmake but a 1.33.1 boost from my old linux distro.
- How should this work in the presence of multiple simultaneous
installed boosts? It looks to me like this isn't a standard use-case
envisioned by find_package, but maybe I'm missing something.
-t