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

[Ben Boeckel]

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
-------------- next part --------------
set(BOOST_ROOT
    "/home/boeckb/misc/root/boost"
    CACHE PATH "")

find_package(Boost REQUIRED
    COMPONENTS
        system)

if (Boost_SYSTEM_LIBRARY MATCHES "^/usr/lib")
    message(FATAL_ERROR "FAIL")
else (Boost_SYSTEM_LIBRARY MATCHES "^/usr/lib")
    message(STATUS "PASS")
endif (Boost_SYSTEM_LIBRARY MATCHES "^/usr/lib")
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bisect.sh
Type: application/x-sh
Size: 375 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111116/bb99115b/attachment-0001.sh>