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
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
