[cmake-developers] Nitpicking ProcessorCount.cmake

David Cole david.cole at kitware.com
Tue Nov 1 10:25:24 EDT 2011


On Tue, Nov 1, 2011 at 6:11 AM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Sunday 23 October 2011, Alexander Neundorf wrote:
>> Hi,
>>
>> I just used ProcessorCount.cmake the first time.
>> I noticed a small issue:
>> AFAIK module file names in cmake use CamelCase, while the macros/functions
>> use underscores: SomeCoolStuff.cmake -> some_cool_stuff()
>>
>> ProcessorCount.cmake doesn't do this, the function is named
>> processorcount()
>>
>> IMO we should keep it this way, since it is defacto-standard, and it also
>> makes sense, since I always recommend to use all-lower-caps style for
>> commands, or at least all-upper-caps.
>> And when using all-lower, the function name is not that easy to read
>> anymore.
>>
>> So, should I rename it to processor_count() and add a processorcount() for
>> backward compatibility ?
>>
>> Alex
>>
>> P.S. it is similar with ExternalPackage.cmake, externalproject_add()
>> doesn't use the old style, it would have been external_project_add()
>> instead. --
>
> Any opinions ?
>
> Alex
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>

I think our intent with the naming introduced by ExternalProject.cmake
(and followed with ProcessorCount.cmake) was to adopt a convention
wherein the names of functions in a module meant for public
consumption should be prefixed with the module name itself, a sort of
poor-man's namespace.

If all modules followed such a convention, then we can avoid multiple
modules defining the same function name by accident.

And even if only the modules I've written follow such a convention, my
function names are unlikely to conflict with those that exist in
another module.

I don't much care for recommending all lowercase or all uppercase as
CMake-language defined function names because then there's no
at-a-glance way to distinguish between built-in commands and
module-defined commands. (But I guess there doesn't really need to be
either... People who need to know more will go looking for the
documentation and find it either way.)

I prefer camel case, personally, because I find it easier to read than
underscore separated. And I read far too much CMake code compared to
the average person. :-)


Just my opinion. Would like to hear others, too.

David C.



More information about the cmake-developers mailing list