CMakeMigration2021

Материал из ALT Linux Wiki
Версия от 18:35, 12 апреля 2021; ArsenyMaslennikov (обсуждение | вклад) (Q: Хочу собирать в один поток!)


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 $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