View Issue Details Jump to Notes ] Print ]
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?

TagsNo tags attached.
Attached Filestxt file icon CMakeLists.txt [^] (7,856 bytes) 2015-03-16 09:32 [Show Content]

 Relationships

  Notes
(0038227)
Brad King (manager)
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 (reporter)
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 (administrator)
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.

 Issue History
Date Modified Username Field Change
2015-03-16 09:32 nagger New Issue
2015-03-16 09:32 nagger File Added: CMakeLists.txt
2015-03-16 17:10 Brad King Note Added: 0038227
2016-04-15 18:28 Jean-Christophe Fillion-Robin Note Added: 0040872
2016-06-10 14:29 Kitware Robot Note Added: 0042731
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team