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.noul...@gmail.com> wrote: > > > > Le mar. 13 nov. 2018 à 10:41, Marc CHEVRIER <marc.chevr...@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 -- 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
