Policies/CMake Coding Style: Difference between revisions

From KDE Community Wiki
(→‎Upper/lower casing: lower-case is preferred over upper-case)
(lowercase)
Line 32: Line 32:
You are free to use pkg-config in FindXXX.cmake modules, as long as the following conditions are met:
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
* 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
* 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.
* 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
* 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.
* 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.

Revision as of 15:47, 17 September 2011

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 (CMake 2.6)

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

CMake commands are case-insensitive (only the commands, not the arguments or variable names). So all the following versions work:

add_executable(foo foo.c)
ADD_EXECUTABLE(bar bar.c)
Add_Executable(hello hello.c)
aDd_ExEcUtAbLe(blub blub.c)

But this would be ugly.

In KDE the all-lowercase style is preferred. Mixing upper- and lowercase should not be done in KDE CMake files.

(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:

readme.txt

  • 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.