[CMake] Boost macro behavior with respect to version

[Adams, Brian M]

I'm curious if the behavior I'm seeing with respect to FindBoost.cmake is expected.  (I realize I'm using these macros in a convoluted way, so understand if I can't make it work more cleanly.)

What I'd like to be able to do is something like the following to probe for a system-provided or user-specified Boost, but then fall back on a distributed one that comes with our software as needed (probably in config instead of module mode, but that's for another day):

find_package(Boost 1.40)
if (NOT Boost_FOUND)
  set(BOOST_ROOT /path/to/boost/in/our/tree)
  find_package(Boost 1.40 REQUIRED)
endif()

I get problems with this, e.g., on RHEL5, which has Boost 1.33 installed.  The first find fails due to version too low, then the second find doesn't probe because it detects Boost settings in the cache.  After the first probe (and in the end) Boost_FOUND is false, AND the include and lib dirs for Boost are set to the 1.33 install location, which is misleading.  It seems odd to me that these variables get set even though the probe failed.

I can perform a workaround where I trick FindBoost.cmake to not use the cache:

find_package(Boost 1.40)
if (NOT Boost_FOUND)
  unset(Boost_INCLUDE_DIR CACHE)
  # these not needed, but could do to be safe:
  #unset(Boost_LIBRARY_DIRS CACHE)
  #unset(Boost_LIB_VERSION CACHE)
  #unset(Boost_VERSION CACHE)
  set(BOOST_ROOT /path/to/boost/in/our/tree)
  find_package(Boost 1.40)
endif()

Then I end up with the 1.40 that I'd expect.  This seems likely to bite me down the road.  How (besides requiring the user to have sufficiently new Boost on their system), should I handle this?

Thanks,
Brian



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110210/1fd26b3d/attachment.htm>