[CMake] Boost macro behavior with respect to version

Ryan Pavlik rpavlik at iastate.edu
Thu Feb 10 17:56:00 EST 2011


I'm not entirely sure why FindBoost uses the cache in the way it does, as it
seems to cause a fair amount of issues.  I've made an experimental
modification of FindBoost.cmake that doesn't use internal cache variables
here: [1] It seems to work in my initial tests, but it's probably not ideal
and I haven't tested it further.

Ryan

[1]
https://github.com/rpavlik/cmake-modules/blob/rework-boost/cmake-2.8.4-modules/boost/FindBoost.cmake

On Thu, Feb 10, 2011 at 2:17 PM, Adams, Brian M <briadam at sandia.gov> wrote:

>  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
>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
Ryan Pavlik
HCI Graduate Student
Virtual Reality Applications Center
Iowa State University

rpavlik at iastate.edu
http://academic.cleardefinition.com
Internal VRAC/HCI Site: http://tinyurl.com/rpavlik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110210/7e2645e5/attachment.htm>


More information about the CMake mailing list