CMakeMigration2021

Rationale

С макросами %cmake, %cmake_build, %cmake_install, %cmakeinstall_std есть несколько проблем:

• Они работают только с генератором Unix Makefiles (в частности, с Ninja не работают).
• В случае размещения сборочных артефактов out-of-source используется гвоздями прибитый каталог BUILD, который невозможно поменять, не отказавшись от макросов.
  • Более того, он ещё и прибит к текущему каталогу.
• %cmake_install работает не очевидным образом (не похож на %cmake_build) и является спойлером для %cmakeinstall_std (аналогично макросам для Make)
• %cmake_build, %cmake_install бесполезны для in-source builds (некоторые мейнтейнеры любят так собирать, вероятно, у них есть на это причины).

Proposed changes

CMake уже несколько лет поддерживает операции build и install, не зависящие от генератора, и операцию configure, не зависящую от текущего каталога.

%build
cmake -S . -B %__builddir \
    $args \
    #
cmake --build %__builddir -j%__nprocs

%install
DESTDIR=%buildroot cmake --install %__builddir

Командам cmake --build и cmake --install можно передать --verbose. Важно: Параметры командной строки --build и --install должны быть первыми.

Автор этих строк вносит предложение ввести такие макросы: http://git.altlinux.org/people/arseny/packages/cmake.git?p=cmake.git;a=shortlog;h=refs/tags/3.19.7-alt2 Их семантика похожа на макросы для Python3, для Meson. Эти макросы можно использовать с любым сборочным исполнителем, с in-source builds; они отвечают рекомендациям апстрима CMake (использовать cmake (--build|--install)). Несколько пакетов в Сизифе уже сопровождаются таким образом.

Возможны варианты:

• не дописывать --verbose к cmake (--build|--install).
• дописать в %cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo, см. https://cmake.org/cmake/help/v3.20/variable/CMAKE_BUILD_TYPE.html.
  • debuginfo-символы будут вынесены в отдельные пакеты средствами соотв. подсистемы RPM, как обычно.

Старые макросы	Предлагаемые макросы
%cmake_install install DESTDIR=%buildroot	%cmake_install
%сmakeinstall_std	%makeinstall_std -C BUILD
cmake --build "%_cmake__builddir" -j%__nprocs	%cmake_build
%cmake_build $target	%cmake_build -t $target
%cmake $args	%cmake -S . -B BUILD $args
%cmake_insource $args	%cmake_insource $args
mkdir -p "%_target_platform" cmake -S . -B "%_target_platform" \ -DCMAKE_SKIP_RPATH:BOOL=ON \ -DCMAKE_SKIP_INSTALL_RPATH:BOOL=yes \ -DCMAKE_C_FLAGS:STRING='%optflags' \ -DCMAKE_CXX_FLAGS:STRING='%optflags' \ -DCMAKE_Fortran_FLAGS:STRING='%optflags' \ -DCMAKE_INSTALL_PREFIX=%prefix \ -DINCLUDE_INSTALL_DIR:PATH=%_includedir \ -DLIB_INSTALL_DIR:PATH=%_libdir \ -DSYSCONF_INSTALL_DIR:PATH=%_sysconfdir \ -DSHARE_INSTALL_PREFIX:PATH=%_datadir \ -DLIB_DESTINATION=%_lib \ -DLIB_SUFFIX="%_libsuff" \ $args	%cmake $args

User-visible impact

Пользователи не заметят изменений.

Incompatibilities

• 8 спеков в Сизифе явно используют старый %cmake_install. Их исправит change owner.
• Каталогом для сборочных артефактов по умолчанию будет выступать не BUILD, а %_target_platform. Мейнтейнерам предстоит либо заменить отсылки к BUILD в спеках на %_cmake__builddir, либо внести в спек:

  %define _cmake__builddir BUILD
  

  для возвращения старого поведения.

Change owners

arseny@

FAQ

Q: Я собираю in-source и не хочу, чтобы вы это сломали.

A: Поведение %cmake_insource не изменится.

Q: Меня всё устраивало, я не хочу ничего менять!

A: Можете вставить %define _cmake__builddir BUILD до обращения к cmake-related макросам.

Q: Хочу собирать в один поток!

A: %define __nprocs 1