[cmake-developers] Module macros/function names with single leading underscore

Craig Scott craig.scott at crascit.com
Sun Jul 23 10:20:31 EDT 2017


Devs,

A merge request
<https://gitlab.kitware.com/cmake/cmake/merge_requests/1067> recently
highlighted how an undocumented CMake feature may result in macros or
functions defined by projects interfering with internal macros or functions
defined by CMake modules. Specifically, if a macro or function name starts
with a single underscore, it can accidentally be replaced. The scenario
goes something like this:


   1. CMake module defines an internal macro _aaa()
   2. Some other code (project or CMake module) defines another macro or
   function with the same name but without the leading underscore. So far, no
   problem.
   3. Project code now defines their own macro or function with the same
   name (i.e. aaa()). The old aaa() macro is renamed to _aaa() and the
   previous _aaa() macro can no longer be called.

The following minimal project demonstrates the scenario, resulting in
infinite recursion at the point noted:

cmake_minimum_required(VERSION 3.0)
project(FooBar)
macro(_doFoo)
    message("Hi from internal doFoo")
endmacro()
macro(doFoo)
    message("Hello from first")
    _doFoo()
endmacro()
doFoo()
macro(doFoo)
    message("Hello from second")
    _doFoo() # Infinite recursion triggered here
endmacro()
doFoo()


It turns out that quite a few CMake modules define internal macros or
functions with names that have a single leading underscore, which means
they are also susceptible to problems like the above. It's probably going
to be an uncommon situation, but maybe it's worth considering renaming
these single underscore internal macros and functions? There seems to be
somewhat of a convention of using two leading underscores in a reasonable
number of CMake's modules, so maybe that's something we can consider
standardising on.

Comments, thoughts, suggestions?

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170724/608d9a54/attachment.html>


More information about the cmake-developers mailing list