[CMake] FindBoost.cmake not (fully) honoring BOOST_ROOT

Alain Leblanc aalebl at gmail.com
Wed Nov 16 12:32:48 EST 2011


This is not a new issue, as you can see in this thread:

http://www.cmake.org/pipermail/cmake/2010-March/035889.html

Very frustrating. I think in the end I removed the system installation. 
May not be an option for everyone.

On 11/16/2011 10:32 AM, Ben Boeckel wrote:
> Hi,
>
> Using the 'release' branch of CMake, it seems that FindBoost.cmake got
> broken such that when BOOST_ROOT is set, the system copy of boost is
> still found, effectively ignoring whatever BOOST_ROOT sets. This doesn't
> work at all for projects where a newer boost than the system version is
> needed.
>
> The first commit I found that has this behavior is
>
>      commit 566647d34f705eeee10815cbdb6b00a170a8aef3
>      Author: Douglas Gregor<doug.gregor at gmail.com>
>      Date:   Thu Jul 3 15:49:41 2008 -0400
>
>          ENH: Cleanup FindBoost module, fixing several small bugs and
>          providing better diagnostic information when things go wrong
>
> which has been in since v2.8.0 and seems odd since the noticed breakage
> is more recent. Testing every commit that has changed FindBoost.cmake
> since then also has the bug. From this, I gather that pretty much
> everyone uses system Boost versions on Linux. Another possibility is
> that since I'm on Fedora, looking for /usr/lib64 may be confusing
> FindBoost.cmake since the locally installed versions use
> ${BOOST_ROOT}/lib instead which would cause it to not be found. However,
> adding a symlink from ${BOOST_ROOT}/lib64 to ${BOOST_ROOT}/lib does not
> resolve the issue.
>
> The bisect.sh script is attached as well as the t/CMakeLists.txt I used.
> It is intended to be run from the CMake source tree. Editing
> t/CMakeLists.txt to point to a different Boost will likely be needed.
> The bisect.sh script expects the tree to look like:
>
>      .../<- a common root
>          build/<- the build tree, will be deleted and
>                        re-bootstrapped on each run
>          src/<- the source tree, run from here
>              t/<- the test tree
>
> Here is a snapshot of the related cache variables from the above test:
>
>      BOOST_ROOT                   /home/boeckb/misc/root/boost
>      Boost_INCLUDE_DIR            /home/boeckb/misc/root/boost/include
>      Boost_LIBRARY_DIRS           /usr/lib64
>      Boost_SYSTEM_LIBRARY         /usr/lib64/libboost_system-mt.so
>      Boost_SYSTEM_LIBRARY_DEBUG   /usr/lib64/libboost_system-mt.so
>      Boost_SYSTEM_LIBRARY_RELEASE /usr/lib64/libboost_system-mt.so
>
> There is Boost_NO_SYSTEM_PATHS, but even without this, the above should
> not happen. Getting mixed include and library paths is silent and an
> easy way to get confusing errors.
>
> Because of this, I propose that FindBoost.cmake have tests added which
> should be run on specific dashboards with a set of local Boost copies to
> help prevent regressions. The tests should ensure that if BOOST_ROOT is
> set, Boost_INCLUDE_DIR, Boost_LIBRARY_DIRS, and Boost_*_LIBRARY* are
> under BOOST_ROOT. A dashboard for at least a Red Hat-based distro and a
> Debian-based distro should be made due to /usr/lib${LIB_SUFFIX}
> differences.
>
>      - Finding a local Boost instead of the system version.
>      - As above, but searching for components.
>      - As above, but searching for a component that is in the system and
>        *not* in the local Boost. This test should either fail (which is
>        easier) or use the system version for everything. It should
>        definitely *not* find some components in the system and some in
>        the local version.
>      - Error when a local Boost does not meet the minimum version
>        requirement and the system version does. A message about unsetting
>        BOOST_ROOT would be nice here.
>      - Tests for ensuring the following are honored similar to the
>        component searches above:
>          Boost_USE_STATIC_LIBS
>          Boost_USE_MULTITHREADED
>
> Any others tests that would be good to have?
>
> --Ben
>
>
> --
>
> 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



More information about the CMake mailing list