MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007725CMakeModulespublic2008-09-23 18:392010-11-09 22:57
Reporterjoaander 
Assigned ToPhilip Lowman 
PrioritynormalSeveritytweakReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionCMake 2.8.3Fixed in VersionCMake 2.8.3 
Summary0007725: BOOST_ROOT unusable in FindBoost.cmake
DescriptionI have two issues with FindBoost.cmake in CMake 2.6.1
 1) Versions of boost in the system path will override newer versions in BOOST_ROOT
 2) The suffix where include files is searched is always boost_version on windows, but boost compiled from source puts include files in boost-version (note the hyphen instead of the underscore.
Steps To Reproduce
Additional InformationI need the setting in BOOST_ROOT to override any system installed boost, as some users of my software need to build it on a machine with an ancient version of boost. They've built boost in a separate location and set BOOST_ROOT, but FindBoost.cmake still picks up the system installed version first since /usr/include is on the search path before the hints. In the attached diff, I've fixed this by removing all default paths if BOOST_ROOT is specified.

For issue 2: I fixed it by changing the path suffix list to include boost boost-version and boost_version on all architectures. This should make everybody happy: those who install the boostpro compiled versions that use boost_version and hand compiled ones that use boost-version.

TagsNo tags attached.
Relationships
duplicate of 0008412closed Philip Lowman Setting BOOST_ROOT does not guarantee boost libraries detected outside BOOST_ROOT are the correct ones 
related to 0008326closed Philip Lowman [patch] FindBoost cannot find libraries from Boost Consulting (_boost_LIBRARIES_SEARCH_DIRS issue) 
Attached Filesdiff FindBoost.cmake.diff (849) 2008-09-23 18:39
https://public.kitware.com/Bug/file/1732/FindBoost.cmake.diff
Issue History
Date ModifiedUsernameFieldChange
2008-09-23 18:39joaanderNew Issue
2008-09-23 18:39joaanderFile Added: FindBoost.cmake.diff
2008-09-23 21:56Bill HoffmanStatusnew => assigned
2008-09-23 21:56Bill HoffmanAssigned To => Douglas Gregor
2009-01-10 09:27Alex NeundorfCategoryCMake => Modules
2009-01-15 01:56Philip LowmanNote Added: 0014561
2009-01-16 04:23Philip LowmanRelationship addedrelated to 0008326
2009-01-16 04:28Philip LowmanNote Added: 0014586
2009-01-16 07:52joaanderNote Added: 0014587
2009-01-16 12:23Philip LowmanNote Added: 0014591
2009-01-16 13:18joaanderNote Added: 0014593
2009-01-16 13:21joaanderNote Edited: 0014593
2009-01-16 14:53Philip LowmanNote Added: 0014594
2009-01-16 17:42joaanderNote Added: 0014595
2009-01-18 16:43Philip LowmanNote Added: 0014606
2009-01-21 00:33Philip LowmanRelationship addedrelated to 0008412
2010-09-10 23:53Philip LowmanAssigned ToDouglas Gregor => Philip Lowman
2010-09-10 23:56Philip LowmanNote Added: 0022188
2010-09-10 23:56Philip LowmanTarget Version => CMake 2.8.3
2010-09-12 22:30Philip LowmanRelationship replacedduplicate of 0008412
2010-09-12 22:30Philip LowmanDuplicate ID0 => 8412
2010-09-12 22:30Philip LowmanStatusassigned => resolved
2010-09-12 22:30Philip LowmanFixed in Version => CMake 2.8.3
2010-09-12 22:30Philip LowmanResolutionopen => fixed
2010-11-09 22:57Philip LowmanStatusresolved => closed

Notes
(0014561)
Philip Lowman   
2009-01-15 01:56   
joaander,

Regarding your post:

Issue #1: Yes I have run into this issue too and am aware of it. I have on more than one occassion had FindBoost fail detecting libraries in my BOOST_ROOT and fallback on a system installed library without a version number on it. Please bear with me as I triage these FindBoost bugs. I think I agree with you on having BOOST_ROOT be treated as a "it must be there" installation prefix as opposed to a "Preferred installation prefix". The user can always call FindBoost twice, IMHO.

Issue 0000002: Can you please try the latest version of FindBoost.cmake and if it doesn't work for you clear your cache and SET(Boost_DEBUG TRUE) and post the results along with which directories of yours are failing. I believe this code here (been present for some time) should fix your issue:

      if (WIN32 AND NOT CYGWIN)
        set(_boost_PATH_SUFFIX boost_${_boost_VER})
      else (WIN32 AND NOT CYGWIN)
        set(_boost_PATH_SUFFIX boost-${_boost_VER})
      endif (WIN32 AND NOT CYGWIN)
(0014586)
Philip Lowman   
2009-01-16 04:28   
joaander,

Sorry, I didn't completely understand your second issue the first time I read your bug report but do now. Issue has been fixed in CVS CMake. For the moment I've only enabled the "_" search when on WIN32. Here's the related code:

Your Issue #1 remains unresolved for the moment.

    FOREACH(_boost_VER ${_boost_TEST_VERSIONS})
      # Add in a path suffix, based on the required version, ideally
      # we could read this from version.hpp, but for that to work we'd
      # need to know the include dir already
      set(_boost_BOOSTIFIED_VERSION)

      # Transform 1.35 => 1_35 and 1.36.0 => 1_36_0
      IF(_boost_VER MATCHES "[0-9]+\\.[0-9]+\\.[0-9]+")
          STRING(REGEX REPLACE "([0-9]+)\\.([0-9]+)\\.([0-9]+)" "\\1_\\2_\\3"
            _boost_BOOSTIFIED_VERSION ${_boost_VER})
      ELSEIF(_boost_VER MATCHES "[0-9]+\\.[0-9]+")
          STRING(REGEX REPLACE "([0-9]+)\\.([0-9]+)" "\\1_\\2"
            _boost_BOOSTIFIED_VERSION ${_boost_VER})
      ENDIF()
      
      LIST(APPEND _boost_PATH_SUFFIXES "boost-${_boost_BOOSTIFIED_VERSION}")
      IF(WIN32)
        # Yay Boost Pro! We dig your underscores.
        LIST(APPEND _boost_PATH_SUFFIXES "boost_${_boost_BOOSTIFIED_VERSION}")
      ENDIF()

    ENDFOREACH(_boost_VER)
(0014587)
joaander   
2009-01-16 07:52   
Cool, nice to see the progress.

As for BOOST_ROOT, I wouldn't mind too much if it was the first place searched vs. being the only place searched. The problem is that with it currently specified in the path hints, the operating system /usr directories are always searched first. No amount of my fiddling could get the search order the other way around, until I found that disabling the system directories from being searched at all worked with the side effect that BOOST_ROOT is then the only place searched.
(0014591)
Philip Lowman   
2009-01-16 12:23   
Actually the BOOST_ROOT paths are searched first because the HINTS option is used instead of PATHS to FIND_LIBRARY() and FIND_PATH(). What probably was happening for you was some other bug which prevented FindBoost from working properly (there are several in the bugtracker which have recently been fixed).

If you want, give the latest version a try and if BOOST_ROOT doesn't work for you clear cache and set Boost_DEBUG to true and run it again. The debugging information should tell us what's going on.

The remaining issue with BOOST_ROOT is that your BOOST_INCLUDE_DIR might get autodetected correctly based on BOOST_ROOT but somehow the FIND_LIBRARY() calls fail (usually due to compiler prefix, i.e. "-gcc43" not matching). Since there is a fallback in FIND_LIBRARY() on filenames *without* the compiler prefix and *without* the boost version, ultimately /usr/local/lib and /usr/lib get searched after BOOST_ROOT and the system boost which may be found may not necessarily be the same version of Boost in BOOST_INCLUDE_DIR. See around FindBoost.cmake:590

    FIND_LIBRARY(Boost_${UPPERCOMPONENT}_LIBRARY_RELEASE
        NAMES ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}-${Boost_LIB_VERSION}
               ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_COMPILER}${_boost_MULTITHREADED}${_boost_STATIC_TAG}-${Boost_LIB_VERSION}
               ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}
               ${Boost_LIB_PREFIX}boost_${COMPONENT}${_boost_MULTITHREADED}${_boost_STATIC_TAG}
               ${Boost_LIB_PREFIX}boost_${COMPONENT}
        HINTS ${_boost_LIBRARIES_SEARCH_DIRS}
    )

The simplest way to fix this would be to either specify NO_DEFAULT_PATH if the user has dictated BOOST_ROOT or omit the checks for versions of Boost without version and compiler encodings (might not be possible to fix it this way).
(0014593)
joaander   
2009-01-16 13:18   
(edited on: 2009-01-16 13:21)
Weird. Well, here is what I've got.
Boost 1.36 was built with
./configure --prefix=/home/joaander/software
make install

Boost 1.35 is installed in the system (gentoo linux).

I just downloaded revision 1.18 FindBoost.cmake from http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindBoost.cmake?root=CMake&view=log [^]

Here is what I get
$ BOOST_ROOT=/home/joaander/software/ cmake -D Boost_DEBUG=on ../src/
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring HOOMD 0.8.0
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found PythonInterp: /usr/bin/python
-- Found PythonLibs: /usr/lib64/libpython2.5.so
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:266 ] boost not in cache
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:268 ] _boost_TEST_VERSIONS = 1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:326 ] Declared as CMake or Environmental Variables:
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:328 ] BOOST_ROOT = /home/joaander/software
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:330 ] BOOST_INCLUDEDIR =
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:332 ] BOOST_LIBRARYDIR =
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:334 ] _boost_TEST_VERSIONS = 1.37.0;1.37;1.36.1;1.36.0;1.36;1.35.1;1.35.0;1.35;1.34.1;1.34.0;1.34;1.33.1;1.33.0;1.33
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:383 ] Include debugging info:
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:385 ] _boost_INCLUDE_SEARCH_DIRS = /home/joaander/software/include;/home/joaander/software;C:/boost/include;C:/boost;/boost;/sw/local/include
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:387 ] _boost_PATH_SUFFIXES = boost-1_37_0;boost-1_37;boost-1_36_1;boost-1_36_0;boost-1_36;boost-1_35_1;boost-1_35_0;boost-1_35;boost-1_34_1;boost-1_34_0;boost-1_34;boost-1_33_1;boost-1_33_0;boost-1_33
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:411 ] location of version.hpp: /usr/include/boost/version.hpp
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:430 ] version.hpp reveals boost 1.35.0
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:508 ] guessed _boost_COMPILER = -gcc41
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:519 ] _boost_MULTITHREADED = -mt
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:535 ] _boost_STATIC_TAG =
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:537 ] _boost_ABI_TAG = d
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:566 ] _boost_LIBRARIES_SEARCH_DIRS = /home/joaander/software/lib;/home/joaander/software/stage/lib;C:/boost/lib;C:/boost;/boost/boost_1_35_0/lib;/boost;/sw/local/lib
-- [ /home/joaander/hoomd/src/CMake/boost/FindBoost.cmake:691 ] Boost_FOUND = TRUE
-- Boost version: 1.35.0
-- Found the following Boost libraries:
-- thread
-- filesystem
-- python
-- signals
-- program_options
-- unit_test_framework
... irrelevant output removed
joaander@pion ~/hoomd/bin_boost $ ls /home/joaander/software/include/boost_1_36/boost/version.hpp
/home/joaander/software/include/boost_1_36/boost/version.hpp
joaander@pion ~/hoomd/bin_boost $

If I'm reading it right, FindBoost.cmake is picking up the BOOST_ROOT setting and then immeadiately finding version.hpp in /usr/include/boost. From the ls at the end, you can see that version.hpp is in $BOOST_ROOT/include/boost_1_36/boost/version.hpp
./configure puts boost in boost_1_36, a path which is now only searched if WIN32 is set.

So, if I take the change you just mentioned
IF(WIN32)
# Yay Boost Pro! We dig your underscores.
LIST(APPEND _boost_PATH_SUFFIXES "boost_${_boost_BOOSTIFIED_VERSION}")
ENDIF()

And comment out the IF and ENDIF, it works!

$ BOOST_ROOT=/home/joaander/software/ cmake -D Boost_DEBUG=on ../src/
....
location of version.hpp: /home/joaander/software/include/boost_1_36/boost/version.hpp
....
The libraries are found correctly too.

I'm unfortunately not on a windows box with the boost pro builds installed right now, so I can't confirm this. But did I get the - and _ backwards? It seems that maybe the command line installations both on windows and linux install to boost_1_36. Is it only the boost pro builds on windows that use the -?
(0014594)
Philip Lowman   
2009-01-16 14:53   
I thought that the "_" was only needed on Windows with BoostPro.

Hmm, when I built boost 1.36.0 with a --prefix of $HOME/boosts I get the following:
/home/lowman/boosts/include
/home/lowman/boosts/include/boost-1_36

Did boost install itself to /home/joaander/software/include/boost_1_36 or did you rename the directory yourself?

I can simply remove the conditional and have Linux check for the "_" although before I do so I want to make sure this is necessary as it does double the number of path suffixes to check which with a larger number of version checks could start to slow the module down.
(0014595)
joaander   
2009-01-16 17:42   
You know, you are probably right. I bet I renamed it when I was trying to figure out what was causing the issue that led to the initial bug report. Sorry for the confusion :(

On both my linux and Mac OS X machines I've now downloaded and compiled boost 1.37.0 and installed it to my home directory with the standard ./configure; make; make install. Using the unmodified 1.18 FindBoost.cmake BOOST_ROOT works without any problems, and 1.37 from my home directory is chosen over an earlier version installed in the system directory.

It also works fine on my Vista x64 install with a hand compiled boost. I'm away from my windows XP box with the boost pro install so I can't test that, but given that you add the _ suffix when WIN32 is set, I don't see any reason why it wouldn't work.

So, it looks like the modifications you made in the 1.18 revision solve both of the original issues and I only created more for myself by renaming files.....
(0014606)
Philip Lowman   
2009-01-18 16:43   
Joaander,

Thanks for helping with the testing and I'm glad it's working for you now. I'm going to leave this bug open while I ponder what to do about the other problem with BOOST_ROOT.
(0022188)
Philip Lowman   
2010-09-10 23:56   
The new Boost_NO_SYSTEM_PATHS option should solve this issue