MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015448CMakeCMakepublic2015-03-16 09:322016-06-10 14:31
Reporternagger 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformWin x64OSWindowsOS VersionWindows 7
Product VersionCMake 3.2.1 
Target VersionFixed in Version 
Summary0015448: find_path() after mark_as_advanced()
DescriptionIt not clear to me if the following is a bug in CMake or just an invalid use:
(I tested this for CMake 2.8.11, 3.0.1 and 3.2.1.)


set(my_path "anyvalue")
find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR})
mark_as_advanced(my_path)
find_path(my_path NAMES CMakeLists.txt HINTS ${CMAKE_CURRENT_LIST_DIR})
message("my_path: '${my_path}'") # my_path is empty here!
 

1st FIND_PATH() uses only the non-cached variable and does not create the cache-variable
* this is not described in the docs
** the docs should also describe when and how the cached-variable and the non-cached variable is read and written
** same goes for all find_*-commands

MARK_AS_ADVANCED() for an undefined cache-variable creates the cache-var with and empty value and type 'UNDEFINED'
* Is this a bug(?)
* It could use the value of the non-cached variable (if there is one)
* or it should not set the VALUE-property of the cached variable
* or set the type to 'STRING'

The 2nd FIND_PATH() does not use the non-cached variable as in the first call, but clears the variable without search for the path
* For me this looks like a bug!
Steps To ReproduceSee attached self-contained CMakeLists.txt with a lot of test cases (T1 .. T8) and its output at the end of the file.

For me T1 and T2 is a bug, at least it should act as in T5 or in T7.

And T9 also seems like a bug since the docs say:
"[...] the search will not be repeated unless the variable is cleared"

And T8 is inconsistent to the other tests: Its overwriting the cached value although the variable is set.


Until now I thought that the cached value is always overwritten with the value of the variable. Is there any reason why it is not?

Additional Information
TagsNo tags attached.
Relationships
Attached Filestxt CMakeLists.txt (7,856) 2015-03-16 09:32
https://public.kitware.com/Bug/file/5404/CMakeLists.txt
Issue History
Date ModifiedUsernameFieldChange
2015-03-16 09:32naggerNew Issue
2015-03-16 09:32naggerFile Added: CMakeLists.txt
2015-03-16 17:10Brad KingNote Added: 0038227
2016-04-15 18:28Jean-Christophe Fillion-RobinNote Added: 0040872
2016-06-10 14:29Kitware RobotNote Added: 0042731
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0038227)
Brad King   
2015-03-16 17:10   
Interesting. I think the following happens in the case in the description (I've not looked at the sample code attachment yet):

* The first find_path uses the non-cached variable since it does not need to search.
* Then mark_as_advanced creates the cache entry. For historical reasons creating a cache entry also un-sets the corresponding non-cached variable of the same name.
* The second find_path now sees the empty-valued cached variable since the non-cached variable is no longer set.

I'll have to think more about what could be done to address this.

Certainly the documentation needs to be updated.
(0040872)
Jean-Christophe Fillion-Robin   
2016-04-15 18:28   
To follow up on this, I encountered this issue while setting CMAKE_AR variable in a toolchain file. It was then reset to an empty string.

The following topic adds a CMake test to easily reproduce the problem: https://github.com/Kitware/CMake/compare/master...jcfr:15448-find_program_after-mark_as_advanced [^]
(0042731)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

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.