MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0016133CMakeCMakepublic2016-05-31 20:272016-06-10 14:21
ReporterAlexis Wilke 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformUbuntuOSLinuxOS Version16.04
Product VersionCMake 3.5.1 
Target VersionFixed in Version 
Summary0016133: NO_DEFAULT_PATH is taken as a path when specified after the PATHS option.
DescriptionI wanted to make sure that I could get a header from my environment (i.e. source tree) first, then from the system if no specific version in the environment was defined there. For this purpose, I used the NO_DEFAULT_PATH option as defined in the documentation:

https://cmake.org/cmake/help/v3.5/command/find_path.html [^]

However, the code would always return path "/usr/include" when I expect (in my specific case) to see path "...path-to-source.../contrib/catch"

I found that by putting the NO_DEFAULT_PATH before the PATHS option, it worked as I first expected. It seems to me, though, that it is not correct. There should be a check and if a path defined after the PATHS option looks like a flag, it should be taken as such and see it as the end of the list of PATHS or HINTS.
Steps To ReproduceThe failing search looks like this:

FIND_PATH(CATCH_INCLUDE_DIR
    catch.hpp
    PATHS
        ${CMAKE_SOURCE_DIR}/contrib/catch
        ${CMAKE_SOURCE_DIR}/contrib
    NO_DEFAULT_PATH
)

IF(NOT CATCH_INCLUDE_DIR)
    # Try again with default paths as per cmake
    FIND_PATH(CATCH_INCLUDE_DIR
        catch.hpp
    )
ENDIF()


My Ubuntu installation includes a catch.hpp under /usr/include. This is because I have the catch package already installed:

apt-get install catch

My source directory includes a contrib/catch/catch.hpp file.

Adding a MESSAGE("Found Path? ")(${CATCH_INCLUDE_DIR}) before the IF() shows us that the CATCH_INCLUDE_DIR is already set and it is "/usr/include" instead of the expected "${CMAKE_SOURCE_DIR}/contrib/catch".

Additional InformationThere is a work around, which makes me think that the problem is that PATHS (and probably HINTS) does not properly recognize NO_DEFAULT_PATH as a flag and no see it as a path...

All I have to do is to put the NO_DEFAULT_PATH ahead of the PATHS specification.

FIND_PATH(CATCH_INCLUDE_DIR
    catch.hpp
    NO_DEFAULT_PATH
    PATHS
        ${CMAKE_SOURCE_DIR}/contrib/catch
        ${CMAKE_SOURCE_DIR}/contrib
)

See also my Stackoverflow.com entry here:

http://stackoverflow.com/questions/37534142/how-do-i-get-cmake-to-choose-the-header-found-in-my-contrib-directory/37534160#37534160 [^]
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2016-05-31 20:27Alexis WilkeNew Issue
2016-06-01 08:27Brad KingNote Added: 0041119
2016-06-01 15:18Alexis WilkeNote Added: 0041121
2016-06-01 15:47Brad KingNote Added: 0041122
2016-06-01 15:47Brad KingStatusnew => resolved
2016-06-01 15:47Brad KingResolutionopen => no change required
2016-06-10 14:21Kitware RobotNote Added: 0041161
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0041119)
Brad King   
2016-06-01 08:27   
I cannot reproduce the reported behavior. Here is my session:

$ cmake --version
cmake version 3.5.2

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 3.5)
project(Issue16133 NONE)
find_path(ZLIB_H_1 zlib.h PATHS ${CMAKE_CURRENT_SOURCE_DIR} NO_DEFAULT_PATH)
find_path(ZLIB_H_2 zlib.h PATHS ${CMAKE_CURRENT_SOURCE_DIR})

$ cmake ..

$ grep ZLIB_H CMakeCache.txt
ZLIB_H_1:PATH=/.../Issue16133
ZLIB_H_2:PATH=/usr/include

One can see the argument parsing state machine here:

  https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindBase.cxx;hb=v3.5.2#l92 [^]

The CheckCommonArgument method is here:

  https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFindCommon.cxx;hb=v3.5.2#l311 [^]
(0041121)
Alexis Wilke   
2016-06-01 15:18   
Ah. I'm not too sure what I have done yesterday, but I just cannot reproduce the problem today...

I cannot see a way to close the issue so I suppose I do not have such permissions. I'll let you take care of it.

Thank you for the URIs to the source code. I also checked that and there is really no way it would miss the names...
(0041122)
Brad King   
2016-06-01 15:47   
Okay, thanks for reporting back.
(0041161)
Kitware Robot   
2016-06-10 14:21   
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.