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?
_________________________________________________________
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
