MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007783CMakeCMakepublic2008-10-07 02:212008-10-23 09:41
Reporteredice 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0007783: FindBoost (2.6.2) does not find correct version even if BOOST_ROOT is set
DescriptionI'm using CMake 2.6.2 (I checked, it is using the latest FindBoost.cmake 1.4.2.7)

I wanted to reopen bug 7456 but it appears the "Reopen" or "Feedback" buttons are unavailable?

Regardless, I have boost 1.33.1 installed at
/home/paul/usr/lnx/include/boost-1_33_1
/home/paul/usr/lnx/lib

I have boost 1.36.0 installed at
/home/paul/usr/lnx/share/boost-1_36_0/include
/home/paul/usr/lnx/share/boost-1_36_0/lib

I set BOOST_ROOT to /home/paul/usr/lnx/share/boost-1_36_0
I set the required version to 1.36.0

However, it will always find and check 1.33.1's version.hpp, and never seems to even check the 1.36.0 files.


I tried analysing the inputs and outputs of line 313
    FIND_PATH(Boost_INCLUDE_DIR
      NAMES boost/config.hpp
      HINTS ${_boost_INCLUDE_SEARCH_DIRS}
      PATH_SUFFIXES ${_boost_PATH_SUFFIXES}
      )

_boost_INCLUDE_SEARCH_DIRS =
 /home/paul/usr/lnx/share/boost-1_36_0/include;/home/paul/usr/lnx/share/boost-1_36_0;C:/boost/include;C:/boost;/boost/boost_1_36_0;/Boost;/sw/local/include

_boost_PATH_SUFFIXES =
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


I am not sure why it does not find 1.36.0's version.hpp first since its path is the first in the list (does not mean highest priority?)


But I am more concerned with WHY is cmake looking for boost in places OTHER than BOOST_ROOT... and why is it looking for versions OTHER than the one I have specified.


What happens if I have 2 x boost 1.36.0 installed? This is very possible - the stock version and a version with something tweaked eg -DBOOST_SIGNALS_NAMESPACE=signalslib (for compatibility with Qt3)


Instead, I am set()ing all of the include paths and library paths manually, to ensure I get the right library.

Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0007456closed Douglas Gregor FindBoost (2.6.1) does not find correct version if BOOST_ROOT is set and another version is installed in /usr 
related to 0008112closed Brad King Regression of CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH with regard to PATH_SUFFIXES 
Attached Filestxt boost_strace_output.txt (17,057) 2008-10-10 02:56
https://public.kitware.com/Bug/file/1763/boost_strace_output.txt
txt CMakeLists.txt (381) 2008-10-10 04:00
https://public.kitware.com/Bug/file/1764/CMakeLists.txt
Issue History
Date ModifiedUsernameFieldChange
2008-10-07 02:21ediceNew Issue
2008-10-07 02:45ediceNote Added: 0013740
2008-10-07 10:12Bill HoffmanStatusnew => assigned
2008-10-07 10:12Bill HoffmanAssigned To => Douglas Gregor
2008-10-07 10:58Brad KingRelationship addedrelated to 0007456
2008-10-09 16:00Brad KingSummary(reopening 0007456): FindBoost (2.6.1) does not find correct version even if BOOST_ROOT is set => FindBoost (2.6.2) does not find correct version even if BOOST_ROOT is set
2008-10-09 16:00Brad KingDescription Updated
2008-10-09 16:10Brad KingNote Added: 0013823
2008-10-09 16:22Brad KingNote Added: 0013824
2008-10-09 17:05Brad KingNote Added: 0013825
2008-10-09 17:05Brad KingAssigned ToDouglas Gregor => Brad King
2008-10-10 02:56ediceFile Added: boost_strace_output.txt
2008-10-10 03:59ediceNote Added: 0013830
2008-10-10 04:00ediceFile Added: CMakeLists.txt
2008-10-13 09:51Brad KingNote Added: 0013859
2008-10-13 09:59Brad KingStatusassigned => closed
2008-10-13 09:59Brad KingNote Added: 0013860
2008-10-13 09:59Brad KingResolutionopen => fixed
2008-10-13 20:25ediceStatusclosed => feedback
2008-10-13 20:25ediceResolutionfixed => reopened
2008-10-13 20:25ediceNote Added: 0013871
2008-10-14 08:43Brad KingNote Added: 0013877
2008-10-23 09:41Brad KingStatusfeedback => closed
2008-10-23 09:41Brad KingResolutionreopened => fixed
2008-11-18 09:56Brad KingRelationship addedrelated to 0008112

Notes
(0013740)
edice   
2008-10-07 02:45   
Note that the title should say 2.6.2 NOT 2.6.1. How do you edit bug titles in Mantis?
(0013823)
Brad King   
2008-10-09 16:10   
I fixed the bug title for you. I think only developers can do it.
(0013824)
Brad King   
2008-10-09 16:22   
What was the exact find_package call you used?

  find_package(Boost 1.36.0 EXACT)

will look for only 1.36.0. However,

  find_package(Boost 1.36.0)

will look for version 1.36.0 *or higher*.

Currently there is a bug that will cause the latter case to find one that is lower if a higher or equal version cannot be found. However, even then it will complain that the found version is too old.

I don't know why it is finding 1.33 when version 1.36 is listed first in the search path. I cannot reproduce that problem. Please try running cmake with 'strace' and grep in the output for 'include/boost' to see exactly where it is looking.
(0013825)
Brad King   
2008-10-09 17:05   
I've fixed the problem of considering paths for versions less than requested:

/cvsroot/CMake/CMake/Modules/FindBoost.cmake,v <-- Modules/FindBoost.cmake
new revision: 1.15; previous revision: 1.14

I'd still like to know the results from strace, though. That is a separate problem.
(0013830)
edice   
2008-10-10 03:59   
Useful tool, strace...

Looks like it is assuming BOOST_ROOT will have root/include/boost-1_36_0/config.hpp

I had compiled it to 'stage' and then pointed boost root at that, so I wanted it to find
root/boost/config.hpp
or
root/include/boost/config.hpp
where include is a dir with a link to boost inside.

I want to keep the boost files all in one (boost) root directory so that the libraries don't all live together in one tremendous /mydev/lib directory. Yes the include files go into /include/boost-etc but all the libs go into /lib

See also attached, the CMakeLists.txt file I used to generate the strace.
(0013859)
Brad King   
2008-10-13 09:51   
Thanks for the strace output. I've found the problem. In fact it doesn't expect root/include/boost-1_36_0/boost/config.hpp and will *eventually* try root/boost/config.hpp but not until after it has tried all the other versions. Of course before it gets there it hits the older version.

This is actually a bug in FIND_PATH (and FIND_LIBRARY, etc.), not in the FindBoost.cmake module. The problem is that they are trying the entire search path with the PATH_SUFFIXES provided and then the entire search path with no suffixes. The correct behavior would be to try each entry in the entire search path each with the PATH_SUFFIXES and then directly before moving on to the next entry.
(0013860)
Brad King   
2008-10-13 09:59   
I've fixed the FIND_PATH problem:

/cvsroot/CMake/CMake/Source/cmFindBase.cxx,v <-- Source/cmFindBase.cxx
new revision: 1.50; previous revision: 1.49

Please try the next 2.6.3 release candidate when it is announced.
(0013871)
edice   
2008-10-13 20:25   
Can I please double-check the fix?

I think I now understand (more of) the problem. But I'm not sure that the fix is correct.

If FindBoost wants to also search in the paths without a suffix, shouldn't it also specify a '/' blank suffix?


The documentation for find_file, strangely documents find_path

http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_file [^]

and it states:
PATH_SUFFIXES can be used to give sub directories that will be appended to the search paths.


So if I were writing a cmake module, I would expect that if I gave find_path some suffixes, it would *only* look in those suffix paths, not in any paths without one of the suffixes.


what do you think?
(0013877)
Brad King   
2008-10-14 08:43   
Certainly you can check the fix, and then re-open the report if it doesn't work. I always close bugs right after fixing them because many reporters don't bother responding once it is fixed and then the bug sits open for months before I notice.

We cannot change the behavior of find_path because existing calls have already been written that expect it to look with and without the suffixes added. Also, when a user sets CMAKE_INCLUDE_PATH or some other variable in his/her environment to point at exactly the location of the header to be found, the command had better find it.

I've updated the PATH_SUFFIXES documentation:

/cvsroot/CMake/CMake/Source/cmFindBase.cxx,v <-- Source/cmFindBase.cxx
new revision: 1.51; previous revision: 1.50