MantisBT - CMake
View Issue Details
0012265CMakeCMakepublic2011-06-10 17:522012-01-02 15:56
Stephen Kelly 
Brad King 
normalminoralways
closedno change required 
CMake-2-8 
 
0012265: ${CMAKE_CURRENT_LIST_DIR} called from a macro or function does not refer to the current directory
This might be fully intentional, but I noticed that inside and macro or function the ${CMAKE_CURRENT_LIST_DIR} refers to the caller.

I found a workaround by setting a variable in the top level. Is this a bug or is there another variable I should use?
No tags attached.
gz cmakelistdir.tar.gz (1,715) 2011-06-10 17:52
https://public.kitware.com/Bug/file/3932/cmakelistdir.tar.gz
Issue History
2011-06-10 17:52Stephen KellyNew Issue
2011-06-10 17:52Stephen KellyFile Added: cmakelistdir.tar.gz
2011-06-13 04:48Alex NeundorfNote Added: 0026845
2011-06-13 05:08Alex NeundorfNote Edited: 0026845bug_revision_view_page.php?bugnote_id=26845#r354
2011-07-29 18:19Brad KingNote Added: 0027127
2011-07-29 18:19Brad KingStatusnew => resolved
2011-07-29 18:19Brad KingResolutionopen => no change required
2011-07-29 18:19Brad KingAssigned To => Brad King
2012-01-02 15:56David ColeNote Added: 0028116
2012-01-02 15:56David ColeStatusresolved => closed

Notes
(0026845)
Alex Neundorf   
2011-06-13 04:48   
(edited on: 2011-06-13 05:08)
It behaves the same way as ${CMAKE_CURRENT_LIST_FILE}, so this behaviour is intentional.
I can remember there were discussion(s) about this on the cmake or cmake-developers mailing list, and this was the outcome. Can't remember the details though.

Alex

(0027127)
Brad King   
2011-07-29 18:19   
The behavior is as intended.

The workaround you propose is already in common usage. Typically if I'm writing a module "MyModule.cmake" then I will put code at the top like

  get_filename_component(_MyModule_LIST_DIR ${CMAKE_CURRENT_LIST_FILE} PATH)

which is the pre-2.8.3 equivalent to

  set(_MyModule_LIST_DIR ${CMAKE_CURRENT_LIST_DIR})

so I can refer to the module location inside functions or macros later.
(0028116)
David Cole   
2012-01-02 15:56   
Closing resolved issues that have not been updated in more than 4 months.