View Issue Details Jump to Notes ] Print ]
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`
TagsNo tags attached.
Attached Files? file icon get_filename_cache.cmake [^] (183 bytes) 2011-11-16 11:39

 Relationships

  Notes
(0027806)
David Cole (manager)
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 (manager)
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 (reporter)
2011-11-16 11:49

Well, actualy i met this bug when i was reconfiguring my cache.
(0027809)
arrowdodger (reporter)
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 (manager)
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 (reporter)
2011-11-16 11:57

Ah, i understand now. Sorry for the noise, i should have understood this on my own.
(0027812)
David Cole (manager)
2011-11-16 12:04

Non-issue, see previous notes.
(0029042)
David Cole (manager)
2012-04-02 10:10

Closing resolved issues that have not been updated in more than 4 months.

 Issue History
Date Modified Username Field Change
2011-11-16 11:39 arrowdodger New Issue
2011-11-16 11:39 arrowdodger File Added: get_filename_cache.cmake
2011-11-16 11:43 David Cole Note Added: 0027806
2011-11-16 11:44 David Cole Note Added: 0027807
2011-11-16 11:45 David Cole Assigned To => David Cole
2011-11-16 11:45 David Cole Status new => assigned
2011-11-16 11:49 arrowdodger Note Added: 0027808
2011-11-16 11:50 arrowdodger Note Added: 0027809
2011-11-16 11:54 David Cole Note Added: 0027810
2011-11-16 11:55 David Cole Note Edited: 0027806
2011-11-16 11:57 arrowdodger Note Added: 0027811
2011-11-16 12:04 David Cole Note Added: 0027812
2011-11-16 12:04 David Cole Status assigned => resolved
2011-11-16 12:04 David Cole Fixed in Version => CMake 2.8.7
2011-11-16 12:04 David Cole Resolution open => no change required
2011-11-16 12:04 David Cole Target Version => CMake 2.8.7
2012-04-02 10:10 David Cole Note Added: 0029042
2012-04-02 10:10 David Cole Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team