Re: [devel] I: cmake macros

[Arseny Maslennikov <arseny@altlinux.org>]

[-- Attachment #1: Type: text/plain, Size: 5019 bytes --]

On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
> On 31.05.2021 15:09, Sergey V Turchin wrote:
> > On Monday, 31 May 2021 15:02:55 MSK Anton Farygin wrote:
> > > Как то не очень красиво получилось:
> > > 
> > > В Sisyphus:
> > > 
> > > $ rpm --eval %cmake_install
> > > DESTDIR="/home/rider/RPM/TMP/%{name}-buildroot" cmake --install
> > > "x86_64-alt-linux-gnu" --verbose
> > > 
> > > в p9:
> > > $ rpm --eval %cmake_install
> > > 
> > >       make INSTALL="/bin/install -p" -C BUILD
> > http://git.altlinux.org/tasks/272559/
> > 
> > А действительно ли надо делать _cmake__builddir отличным от "BUILD" по
> > умолчанию?

В p9 — точно себе дороже.

> > 
> Я знаю про это задание, но в этом изменении слишком кардинально меняется
> содержимое макроса, что вряд ли приемлемо для stable репозитория.
> 
> Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает.

В 272559 все пакеты, явно использовавшие %cmake_install в его
(бесполезном, кмк) старом значении, исправлены.
> 
> Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии
> по этому поводу.

Одна из преследуемых целей — спеки не должны зависеть от конкретного
значения %_cmake__builddir, которое они не выставили явно, поэтому их
исправление там, где в них явно про некоторые файлы написано BUILD/*,
всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
список всех пакетов, нарушающих этот принцип.

Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
вероятности могут уже присутствовать в
/usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
`mkdir %_cmake__builddir'. В долгосрочной перспективе нам уместно
(медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90%
писать автоматически.

Остаётся только одно соображение в защиту имени BUILD: при ручном
вмешательстве человека с клавиатурой в хешерницу с результатом
почему-либо упавшей сборки %_target_platform (или первые 1-2 символа и
tab-complete) придётся набирать руками. С этой точки зрения значение по
умолчанию "build-%_target_platform" или даже "build" было бы лучше, а
"BUILD" — хуже этих двух, потому что shift надо нажимать и коллизия с
/usr/src/RPM/BUILD.

Вот я и остановился перед выбором из четырёх:
%_target_platform, build-%_target_platform, build, build-%name-%EVR и
выбрал первое. Но я на своём варианте не настаиваю, и об этом умолчании
можно договориться и поменять в сизифе в любой момент обозримого
будущего, не сломав ни один спек.

Так оказалось, что %_target_platform довольно удобен:
конкретно %_target_platform уже используется у нас в макросах для meson,
например; никто не жаловался на возникающие сбои. Да и при чтении лога
семейство архитектур лишний раз бросается в глаза. В самих спеках
%_target_platform явно употребляться не будет, коллизия по имени с уже
существующими файлами маловероятна.

Константным выражением, на которое можно положиться в спеке, выступает
%_cmake__builddir; многие исправленные спеки в обсуждаемом сборочном
задании явно используют этот макрос там, где cmake --install не хватает
и надо руками залезть.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]