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. 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). Le mar. 13 nov. 2018 à 09:59, Eric Noulard <eric.noul...@gmail.com> a écrit : > > > Le mar. 13 nov. 2018 à 00:21, Craig Scott <craig.sc...@crascit.com> a > écrit : > >> >> >> On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke <j.wut...@fz-juelich.de> >> wrote: >> >>> My understanding was that prevalent usage in modern CMake >>> is all lowercase for function names, all uppercase for >>> macro names. In this sense, I submitted a number of merge >>> requests where function and macro names are normalized, and >>> in >>> https://gitlab.kitware.com/cmake/cmake/merge_requests/2607 >>> I suggest an explicit recommendation in the macro and >>> function doc pages. >>> >>> Now I am learning from Craig Scott that the more recent >>> convention is actually all lowercase for macros as well >>> as for functions. >>> >> >> To be clear, my understanding is that in the past (many years ago), >> uppercase tended to be common, but I don't see that used much these days >> for functions, macros or built-in commands. The general sentiment seems to >> be that uppercase tends to be a bit "shouty" now. I'm suggesting that if >> we're going to bring some consistency to the docs, I propose that we just >> go with lowercase everywhere (functions, macros, built-in commands and >> examples). >> >> <nit-filter ON> >> Regarding the finer points of macros versus functions versus built-in >> commands and establishing a convention, it's actually a bit difficult to >> draw a hard line in behaviour across all three. Consider commands like >> find_package() and project(). These are built-in commands, but they behave >> like a macros in that they add variables to the calling scope (yes, >> functions can do that too, but the primary reason to use macros is to >> inject variables into the calling scope). Most built-in commands act more >> like functions and do not modify the calling scope. Trying to decide >> whether built-in commands act like macros and which do not and making them >> upper or lowercase based on that is unlikely to be a distinction that most >> users would make, so a mix of upper and lowercase for built-in commands >> would be unexpected. A consequence of this is that having macros and >> functions with differing case conventions would seem to create a potential >> inconsistency with whatever convention is used for built-in commands. The >> only way to really have consistency here would seem to be just use the one >> case convention, for which lowercase seems to be the logical and >> increasingly prevalent choice. >> <nit-filter OFF> >> > > I would add that sometimes useful macro/function may become builtin > See example for include_guard in > https://github.com/dev-cafe/cmake-cookbook/blob/master/chapter-07/recipe-06/example/CMakeLists.txt > > So differentiating macro/function/builtin by their case does not seems a > good option to me. > My personal opinion though. > > +1 for lower case for every function, macro or builtin. > macro or function OPTION are UPPERCASE > properties are UPPERCASE as well > and I personnally tend to define CMake VARIABLES as uppercase too. > > > -- > 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
