Policies/CMake Coding Style: Difference between revisions
new "End Commands" section |
|||
Line 16: | Line 16: | ||
==Upper/lower casing== | ==Upper/lower casing== | ||
Most important: use consistent upper- or lowercasing within one file ! | |||
In general, in KDE the '''all-lowercase''' style is preferred. | |||
So, this is recommended: | |||
<syntaxhighlight lang="cmake"> | <syntaxhighlight lang="cmake"> | ||
add_executable(foo foo.c) | add_executable(foo foo.c) | ||
</syntaxhighlight> | |||
This is also acceptable: | |||
<syntaxhighlight lang="cmake"> | |||
ADD_EXECUTABLE(bar bar.c) | ADD_EXECUTABLE(bar bar.c) | ||
</syntaxhighlight> | |||
Mixed casing as shown below works too, but should '''not''' be done within KDE: | |||
<syntaxhighlight lang="cmake"> | |||
Add_Executable(hello hello.c) | Add_Executable(hello hello.c) | ||
aDd_ExEcUtAbLe(blub blub.c) | aDd_ExEcUtAbLe(blub blub.c) | ||
</syntaxhighlight> | </syntaxhighlight> | ||
== End commands == | == End commands == |
Revision as of 20:04, 14 January 2012
This document describes the recommended coding style for CMake files in KDE, i.e. CMakeLists.txt files and *.cmake files.
Indentation
Indent all code correctly, i.e. the body of
- if/else/endif
- foreach/endforeach
- while/endwhile
- macro/endmacro
- function/endfunction
Use spaces for indenting, 2, 3 or 4 spaces preferably. Use the same amount of spaces for indenting as is used in the rest of the file. Do not use tabs.
Upper/lower casing
Most important: use consistent upper- or lowercasing within one file !
In general, in KDE the all-lowercase style is preferred.
So, this is recommended:
add_executable(foo foo.c)
This is also acceptable:
ADD_EXECUTABLE(bar bar.c)
Mixed casing as shown below works too, but should not be done within KDE:
Add_Executable(hello hello.c)
aDd_ExEcUtAbLe(blub blub.c)
End commands
To make the code easier to read, use empty commands for endforeach(), endif(), endfunction(), endmacro() and endwhile(). Also, use empty else() commands.
For example, do this:
if(FOOVAR) some_command(...) else() another_command(...) endif()
and not this:
if(FOOVAR) some_command(...) else(FOOVAR) another_command(...) endif(FOOVAR)
(Not) Using pkg-config
You are free to use pkg-config in FindXXX.cmake modules, as long as the following conditions are met:
- the FindXXX.cmake must also work without pkg-config, as long as the package is either installed to one of the default locations (as /usr or /usr/local) or if CMAKE_PREFIX_PATH is set accordingly
- use only find_package(PkgConfig), don't use include(UsePkgConfig), this one is deprecated
- make sure the variables created by pkg_check_modules() are all prefixed with "PC_", so they don't mix up with other variables, e.g. set via find_path() etc.
- FindLibXml2.cmake as shipped with CMake 2.8.5 is a good example how pkg-config should be handled
- putting something like if(NOT WIN32) around the pkg-config stuff is not necessary (and should be removed if it is somewhere). If pkg-config is not found, e.g. on Windows, the macros simply do nothing.
Writing CMake Find-modules
- Follow the style guide from CMake when writing some FindFoo.cmake module:
- For checking the results inside the Find-module, the macro find_package_handle_standard_args() (coming with CMake) should be used, using the new extended syntax, which supports also version checking.
- Micro-optimizations like
if(FOO_LIBRARY AND FOO_INCLUDE_DIR) set(FOO_FOUND TRUE) else() ... execute the whole find-logic endif()
should be removed, the find-logic should be executed always. These shortcuts can cause problems e.g. when the same file is used from multiple directories but e.g. with different required versions or components etc.