View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008112CMakeCMakepublic2008-11-18 01:262008-11-18 09:59
ReporterPhilip Lowman 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008112: Regression of CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH with regard to PATH_SUFFIXES
DescriptionNot sure if this is a bug or not, I suspect it is and it was accidently caused by the addition of CMAKE_PREFIX_PATH. Regardless, it's a change in behavior I noticed between 2.4.8 and 2.6.x that has caused a bit of grief and could continue to cause some people grief so it's worth mentioning.

In CMake 2.4.8 the FIND_LIBRARY and FIND_PATH commands would *always* check for the files in CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH regardless of what was specified in PATH_SUFFIXES. That is to say that PATH_SUFFIXES did not apply to CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH but only to the paths listed after the PATHS command. In CMake 2.6.x that behavior changed. The net effect is that the ability to override the detection of libraries and header files over system defaults with CMAKE_LIBRARY_PATH and CMAKE_INCLUDE_PATH has changed. In fact now your ability to override defaults is at the complete whim of the Find module maintainer and could change at any time.

Example to reproduce:
1. Pick a system header and library already present on your system. For this example I have chosen /usr/lib/libanl* and /usr/include/term.h

2. Create a folder called "my_override" with the following directory structure:
      my_override/include/term.h
      my_override/lib/libanl.a

3. Create this CMakeLists.txt:

PROJECT(foo)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4)

SET(MY_OVERRIDE_ROOT "" CACHE FILEPATH "Override a couple of common libs")
IF(MY_OVERRIDE_ROOT)
   # Works in 2.4.8, fails in 2.6.2
   SET(CMAKE_INCLUDE_PATH ${MY_OVERRIDE_ROOT}/include)
   SET(CMAKE_LIBRARY_PATH ${MY_OVERRIDE_ROOT}/lib)
ENDIF(MY_OVERRIDE_ROOT)

FIND_LIBRARY(ANL_LIBRARY NAMES anl anl2
             HINTS
             $ENV{ANLLOC}
             PATH_SUFFIXES lib64 lib
             PATHS
                /usr/local
                /usr
)
FIND_PATH(TERM_INCLUDE_DIR term.h
             PATH_SUFFIXES include
             PATHS
                /usr/local
                /usr
                /sw
)

4. Using 2.4.8 or 2.6.2 perform an initial configure of your build tree. Note that ANL_LIBRARY and TERM_INCLUDE_DIR are picked up in /usr

5. Delete ANL_LIBRARY and TERM_INCLUDE_DIR from the Cache and specify MY_OVERRIDE_ROOT in the cache to be the /path/to/my_override folder you created earlier. CMake 2.4.8 will discover your new libraries but CMake 2.6.2 will not and will fallback on the system headers/libraries.

You can also reproduce this problem at the command prompt by specifying CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH with the -D directives.

If it was the attempt for CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to be governed by PATH_SUFFIXES it beckons the question why something like CMAKE_PREFIX_PATH was ever added to begin with? I believe the biggest issue, however, is the "improvement" of Find modules breaking behavior for the end user. Consider the following case:

1. Random FindFoo.cmake changes in CMake trunk from this poorly written example:

FIND_LIBRARY(FOO_LIBRARY NAMES foo
               PATHS
                   /usr/local/lib64
                   /usr/local/lib
                   /usr/lib64
                   /usr/lib
                   /sw/lib64
                   /sw/lib
)

To something not quite as bad thanks to PATH_SUFFIXES

FIND_LIBRARY(FOO_LIBRARY NAMES foo
                    PATH_SUFFIXES lib64 lib
                    PATHS
                        /usr/local
                        /usr
                        /sw
)

Woops, Joe's definition of CMAKE_INCLUDE_PATH (which he was applying in a scripted command line option by the way which has worked since CMake 2.4.x) just broke.
TagsNo tags attached.
Attached Files

 Relationships
related to 0007783closedBrad King FindBoost (2.6.2) does not find correct version even if BOOST_ROOT is set 

  Notes
(0014133)
Brad King (manager)
2008-11-18 09:58

 The cause of this is the same as issue 0007783. Basically the PATH_SUFFIXES should be tried on each search location before moving on to the next, but instead they were being tried on all search locations before trying any search location without a suffix. This change was the fix to that issue:

/cvsroot/CMake/CMake/Source/cmFindBase.cxx,v <-- Source/cmFindBase.cxx
new revision: 1.50; previous revision: 1.49
(0014134)
Brad King (manager)
2008-11-18 09:59

 This fix will be included in the 2.6.3 release.

 Issue History
Date Modified Username Field Change
2008-11-18 01:26 Philip Lowman New Issue
2008-11-18 09:40 Bill Hoffman Status new => assigned
2008-11-18 09:40 Bill Hoffman Assigned To => Brad King
2008-11-18 09:56 Brad King Relationship added related to 0007783
2008-11-18 09:58 Brad King Note Added: 0014133
2008-11-18 09:59 Brad King Note Added: 0014134
2008-11-18 09:59 Brad King Status assigned => closed
2008-11-18 09:59 Brad King Resolution open => fixed

Copyright © 2000 - 2018 MantisBT Team