CMake Packaging Guidelines
You will generally make use of these in your specs:
Defines CFLAGS, LDFLAGS, etc. and calls
%__cmakewith appropriate parameters (
-DCMAKE_INSTALL_PREFIX:PATH=/usrand such). You can pass
-Doption=valueto this macro in order to set options for the buildsystem.
Builds the project (using
Installs the built project (using
Runs the tests that are defined with
add_test()in project (using
When packaging KDE software,
you most likely would replace
that defines multiple KDE-related variables (shipped in
It is rarely necessary (but permissible) to use or alter these: NOTE: All macros starting with double underscore is meant to be private, NOT stable and likely to be removed in the future.
The path to the cmake executable.
The path to the ctest executable.
Controls whether builds are done in-source (when defined) or out-of-source (when undefined). See the Defining source and build directories for more information.
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, which should be used preferably in such cases. See the Defining source and build directories for more information. When doing in-source builds (that means before Fedora 33 out-of-source builds change), this macro would differ from
%_vpath_builddirand it will hold the actual location that was used for the build. This is useful in cases, when you want to use the same specfile for different Fedora releases where on some the build is in-source and on some out-of-source AND you need to know the builddir location - e.g. when using
cmake -B %__cmake_builddir -LHbetween
%cmake_build. Whenever possible, using out-of-source builds is advised, as this is the direction both Fedora and CMake upstream are moving.
This macro is suitable only for rare compatibility reasons.
Once all active Fedora releases will use
this macro will be redundant (same as
Since Fedora 33,
%__cmake_in_source_build is not defined
so if you want to have consistent behavior across different releases,
make sure to
%undefine it accordingly.
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).
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
CMake has good documentation in two places: * https://cmake.org/documentation/ * https://gitlab.kitware.com/cmake/community/wikis/Home