Is there any plan to introduce CMAKE_CURRENT_MACRO_LIST_DIR which works like the CMAKE_CURRENT_FUNCTION_LIST_DIR that was added in CMake 3.17? I have run into a use case related to the setup up an environment. There I can’t use a function, but have to use a macro, because things in the parent scope have to be changed and some local CMake files have to be included. My current work-around is what had to be done before CMAKE_CURRENT_FUNCTION_LIST_DIR existed. Create a helper var that stores CMAKE_CURRENT_LIST_DIR and then use this in the macro - hoping nobody modified it.
Macros don’t have their own variable scope. The ${arg} references to their arguments are evaluated as placeholder substitution rather than variable evaluation. One may be able to implement ${CMAKE_CURRENT_MACRO_LIST_DIR}, but it would probably have to be as a placeholder substitution. Maybe it could even be done at the time the macro is defined/recorded.
I can see you point and maybe asking for CMAKE_CURRENT_MACRO_LIST_DIR could be seen as an indication that my approach is fundamentally broken. Seem I try to use a macro ‘foo’ as a way to replace a include('foo.cmake'), where foo.cmake basically contains what the macro contains. The reason I’m doing this is, because I also have a macro bar that would need a file bar.cmake in the same folder then - and I want to have all in one file. The other way to solve this would be
If you decide to go down the route of including the file and selectively enabling just bits of it (USE_FOO x USE_BAR), I suggest a small usability improvement: disable all the switches at the end of the file:
Thanks for the tip. My fear with this would just be, that it becomes even more “magical” then. I was actually thinking that having a new macro there might hide this