[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