[cmake-developers] Preferred case for macro names?

[David Cole]

I would just like to point out that some modules (ExternalData,
ExternalProject, to name two specific examples) adopted the convention
to prefix all their provided function names with the module name and
an underscore: for example, ExternalProject_Add and
ExternalData_Expand_Arguments.

These functions adopt a mixed-case function naming convention, since
the module name is mixed case, and since module names are file names,
and some file systems have case sensitive file names ...... they
should stay that way regardless of any convention you may like to try
to adopt elsewhere.


David C.

On Tue, Nov 13, 2018 at 5:36 AM Eric Noulard <eric.noulard at gmail.com> wrote:
>
>
>
> Le mar. 13 nov. 2018 à 10:41, Marc CHEVRIER <marc.chevrier at gmail.com> a écrit :
>>
>> I agree as well that trying to distinguish macros from functions is not a good idea because functions can act in the same way as macros (i.e. changing calling environment) but with a better control over environment changes (changes are done explicitly by using 'set(... PARENT_SCOPE)').
>>
>> so also +1 for lower case for every function, macro or builtin. And good point to standardize  macro or function OPTION to UPPERCASE.
>>
>> Now, for variables, the problem is a bit different because they are case sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two different variables.
>
>
> Yes damn right.
>
>>
>> My personal tendency is to use lower case for local variables and upper case for global variables. May be we can normalize variables to upper case regarding global variables used by CMake itself (which is globally the current rule).
>
>
> Having a convention for local is nice and I tend to prefix with _ (single or double) variables that should be local.
> lowercasing locals is fine too, however I think that enforcing casing on "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and CPACK_
> I guess they already are all UPPERCASE so we may stick with this as a convention?
>
> A small quote to the cmake-format (https://github.com/cheshirekow/cmake_format) tool which is trying to beautify CMakeLists.txt, I'm not using it on complex projects
> because it still has some issues but I find it otherwise useful.
>
>
> --
> Eric
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers