[CMake] Modules with additional files

David Cole david.cole at kitware.com
Wed Dec 29 15:47:29 EST 2010


On Wed, Dec 29, 2010 at 2:27 PM, Johannes Wienke
<jwienke at techfak.uni-bielefeld.de> wrote:
> Hey again,
>
> Am 29.12.2010 20:23 schrieb Johannes Wienke:
>> Am 29.12.2010 19:53 schrieb Michael Jackson:
>>> I don't understand what you mean by a "module". If you are in a CMakeLists.txt or *.cmake file that is being parsed by CMake then you have access to CMAKE_CURRENT_LIST_FILE. I think I am missing something about your particular setup. Maybe some more details would help us.
>>
>> Confusing, I thought I checked this twice that CMAKE_CURRENT_LIST_*
>> always only points to CMakeLists.txt files, but it works perfectly. ;)
>>
>> Thanks alot, I must have been really tired. ;)
>
> Ok, now I understand my original problem: In one of these modules there
> is a function defined which originally used CMAKE_CURRENT_LIST_DIR. When
> this function is used, CMAKE_CURRENT_LIST_DIR is set to the list file of
> the function caller. Somehow I would have expected this behavior only
> for macros and not for functions. Is this intended?
>
> Johannes
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>

Variables inside functions inherit their values from the calling
scope. If you need the value of the CMAKE_CURRENT_LIST_DIR in a
function that points to the directory containing the file that the
function is defined in, then you should do something like this:

# MyModule.cmake
set(MyModule_DIR "${CMAKE_CURRENT_LIST_DIR}")
  # important that this set call is at file scope outside of function
declarations...

function(that_needs_list_dir ...)
  set(dir "MyModule_DIR")
  # use ${dir} here if necessary
endfunction()

Of course, you're subject to global variable name clashes at this
point.... so the global variable name should somehow incorporate the
name of the file it lives in, and perhaps be named more cleverly than
my example here so that you can avoid colliding with some other
module's variable name.

More context (sample code from your modules) would help us answer your
questions more effectively....

By the way, CMAKE_CURRENT_LIST_DIR is new. It's only in CMake 2.8.3 and later.


HTH,
David


More information about the CMake mailing list