MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012580CMakeCMakepublic2011-11-16 11:392012-04-02 10:10
Reporterarrowdodger 
Assigned ToDavid Cole 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product VersionCMake 2.8.6 
Target VersionCMake 2.8.7Fixed in VersionCMake 2.8.7 
Summary0012580: get_filename_component behavior depends on CACHE keyword
DescriptionI'm running attached file with `cmake -P` and see this:

- DIR: /usr/local/include/dir
-- DIR: /usr/local/include

which is excepted. However, when i add CACHE keyword to the second get_filename_component() invocation i see this:

-- DIR: /usr/local/include/dir
-- DIR: /usr/local/include/dir

Not sure if it's a bug, but looks suspicious.
Steps To ReproduceRun attached script with `cmake -P`
Additional Information
TagsNo tags attached.
Relationships
Attached Files? get_filename_cache.cmake (183) 2011-11-16 11:39
https://public.kitware.com/Bug/file/4119/get_filename_cache.cmake
Issue History
Date ModifiedUsernameFieldChange
2011-11-16 11:39arrowdodgerNew Issue
2011-11-16 11:39arrowdodgerFile Added: get_filename_cache.cmake
2011-11-16 11:43David ColeNote Added: 0027806
2011-11-16 11:44David ColeNote Added: 0027807
2011-11-16 11:45David ColeAssigned To => David Cole
2011-11-16 11:45David ColeStatusnew => assigned
2011-11-16 11:49arrowdodgerNote Added: 0027808
2011-11-16 11:50arrowdodgerNote Added: 0027809
2011-11-16 11:54David ColeNote Added: 0027810
2011-11-16 11:55David ColeNote Edited: 0027806bug_revision_view_page.php?bugnote_id=27806#r453
2011-11-16 11:57arrowdodgerNote Added: 0027811
2011-11-16 12:04David ColeNote Added: 0027812
2011-11-16 12:04David ColeStatusassigned => resolved
2011-11-16 12:04David ColeFixed in Version => CMake 2.8.7
2011-11-16 12:04David ColeResolutionopen => no change required
2011-11-16 12:04David ColeTarget Version => CMake 2.8.7
2012-04-02 10:10David ColeNote Added: 0029042
2012-04-02 10:10David ColeStatusresolved => closed

Notes
(0027806)
David Cole   
2011-11-16 11:43   
(edited on: 2011-11-16 11:55)
CACHE is not a valid keyword in the get_filename_component command.

What is the exact line of code you reference when you say "add CACHE keyword to the second get_filename_component() invocation"...?

[
  EDIT:

  Correction: CACHE is totally a valid keyword in the get_filename_component call, as documented. I had just never really used it that way before... Sorry for the mis-information in the original note.
]
(0027807)
David Cole   
2011-11-16 11:44   
Additionally...... there is no "CACHE" when you are running a cmake -P script, there's only the current script context. -P scripts run independent of the CMakeCache.txt file that is associated with a CMake-configured build tree.
(0027808)
arrowdodger   
2011-11-16 11:49   
Well, actualy i met this bug when i was reconfiguring my cache.
(0027809)
arrowdodger   
2011-11-16 11:50   
Documentation says it's valid to use CACHE in get_filename_component:
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:get_filename_component [^]

>What is the exact line of code you reference when you say "add CACHE keyword to the second get_filename_component() invocation"...?

Line 5.
(0027810)
David Cole   
2011-11-16 11:54   
Ah... you're correct. Sorry. I never use it that way.

If CACHE is used, then the only time the variable will be set is on the first successful call to the command that caches the value. All subsequent calls will simply use the value in the CACHE.

If you have a series of get_filename_component calls that you have to make, I would recommend making them all without CACHE, and then simply using a set(... CACHE) call at the end to cache the final result.

This is expected behavior, and not a "bug"... So I'll resolve this issue.
(0027811)
arrowdodger   
2011-11-16 11:57   
Ah, i understand now. Sorry for the noise, i should have understood this on my own.
(0027812)
David Cole   
2011-11-16 12:04   
Non-issue, see previous notes.
(0029042)
David Cole   
2012-04-02 10:10   
Closing resolved issues that have not been updated in more than 4 months.