CMake Packaging Guidelines

This document provides best practices for the usage of the CMake build system in Fedora packages.

Dépendances de compilation

Vous DEVEZ ajouter les BuildRequires suivants :

BuildRequires: cmake

Macros disponibles

Dans vos specs, vous utiliserez généralement les macros suivantes :

%cmake

Defines CFLAGS, LDFLAGS, etc. and calls %__cmake with appropriate parameters (-DCMAKE_INSTALL_PREFIX:PATH=/usr and such). You can pass -Doption=value to this macro in order to set options for the buildsystem.

%cmake_build

Builds the project (using %__cmake --build).

%cmake_install

Installs the built project (using %__cmake --install).

%ctest

Runs the tests that are defined with add_test() in project (using %__ctest).

When packaging KDE software, you most likely would replace %cmake with either %cmake_kf5 or %cmake_kf6. For more information, see KDE Packaging Guidelines.

Il est rarement nécessaire (mais permis) d’utiliser ou d’altérer les macros suivantes :

All macros starting with double underscore is meant to be private, NOT stable and likely to be removed in the future.
%__cmake

The path to the cmake executable.

%__ctest

The path to the ctest executable.

%__cmake_in_source_build

Controls whether builds are done out-of-source (when undefined, the default) or in-source (when defined). Whenever possible, using out-of-source builds is advised, as this is the direction both Fedora and CMake upstream are moving.

%__cmake_builddir

Holds the location of the actual directory where the build was made. When making out-of-source builds, this macro is the same as %_vpath_builddir. When doing in-source builds, this macro will hold the actual location that was used for the build.

This macro is suitable only for rare compatibility reasons. For normal out-of-source builds, this macro is the same as %_vpath_builddir. It may be removed in the future.

Example Usage

%build
%cmake
%cmake_build

%install
%cmake_install

%check
%ctest

Notes

-DCMAKE_SKIP_RPATH:BOOL=ON. With recent cmake-2.4, it should not be used. This CMake version should handle RPATHs issues correctly (set them in build-dir, remove them during installation). Setting CMAKE_SKIP_RPATH for this version would avoid RPATHs in build-dir too. This might link binaries against system-libraries (e.g. when a previous version of the package was installed) instead of the libraries which were created by the build.

Nevertheless, RPATH issues might arise when CMake was used improperly. For example, installing a target with INSTALL(FILES ... RENAME ...) will not strip rpaths; in this case INSTALL(TARGETS ...) must be used in combination with changing the OUTPUT_NAME property.

CMake has good documentation in two places: