(0014561)
Philip Lowman (developer)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (developer)
2010-09-10 23:56

The new Boost_NO_SYSTEM_PATHS option should solve this issue

Issue History
Date Modified	Username	Field	Change
2008-09-23 18:39	joaander	New Issue
2008-09-23 18:39	joaander	File Added: FindBoost.cmake.diff
2008-09-23 21:56	Bill Hoffman	Status	new => assigned
2008-09-23 21:56	Bill Hoffman	Assigned To	=> Douglas Gregor
2009-01-10 09:27	Alex Neundorf	Category	CMake => Modules
2009-01-15 01:56	Philip Lowman	Note Added: 0014561
2009-01-16 04:23	Philip Lowman	Relationship added	related to 0008326
2009-01-16 04:28	Philip Lowman	Note Added: 0014586
2009-01-16 07:52	joaander	Note Added: 0014587
2009-01-16 12:23	Philip Lowman	Note Added: 0014591
2009-01-16 13:18	joaander	Note Added: 0014593
2009-01-16 13:21	joaander	Note Edited: 0014593
2009-01-16 14:53	Philip Lowman	Note Added: 0014594
2009-01-16 17:42	joaander	Note Added: 0014595
2009-01-18 16:43	Philip Lowman	Note Added: 0014606
2009-01-21 00:33	Philip Lowman	Relationship added	related to 0008412
2010-09-10 23:53	Philip Lowman	Assigned To	Douglas Gregor => Philip Lowman
2010-09-10 23:56	Philip Lowman	Note Added: 0022188
2010-09-10 23:56	Philip Lowman	Target Version	=> CMake 2.8.3
2010-09-12 22:30	Philip Lowman	Relationship replaced	duplicate of 0008412
2010-09-12 22:30	Philip Lowman	Duplicate ID	0 => 8412
2010-09-12 22:30	Philip Lowman	Status	assigned => resolved
2010-09-12 22:30	Philip Lowman	Fixed in Version	=> CMake 2.8.3
2010-09-12 22:30	Philip Lowman	Resolution	open => fixed
2010-11-09 22:57	Philip Lowman	Status	resolved => closed

Notes
(0014561) Philip Lowman (developer) 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 (developer) 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 (reporter) 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 (developer) 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 (reporter) 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 (developer) 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 (reporter) 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 (developer) 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 (developer) 2010-09-10 23:56	The new Boost_NO_SYSTEM_PATHS option should solve this issue