[devel] циферки (was: I: cmake macros)

[Arseny Maslennikov]

On Mon, May 31, 2021 at 05:39:54PM +0300, Andrey Savchenko wrote:
> On Mon, 31 May 2021 16:52:20 +0300 Arseny Maslennikov wrote:
> > On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> > > On Mon, 31 May 2021 15:53:25 +0300 Arseny Maslennikov wrote:
> > > > On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
> > > > > On 31.05.2021 15:09, Sergey V Turchin wrote:
> > > > > > 
> > > > > Я знаю про это задание, но в этом изменении слишком кардинально меняется
> > > > > содержимое макроса, что вряд ли приемлемо для stable репозитория.
> > > > > 
> > > > > Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает.
> > > > 
> > > > В 272559 все пакеты, явно использовавшие %cmake_install в его
> > > > (бесполезном, кмк) старом значении, исправлены.
> > > > > 
> > > > > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии
> > > > > по этому поводу.
> > > > 
> > > > Одна из преследуемых целей — спеки не должны зависеть от конкретного
> > > > значения %_cmake__builddir, которое они не выставили явно, поэтому их
> > > > исправление там, где в них явно про некоторые файлы написано BUILD/*,
> > > > всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
> > > > список всех пакетов, нарушающих этот принцип.
> > > > 
> > > > Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
> > > > вероятности могут уже присутствовать в
> > > > /usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
> > > > неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
> > > > `mkdir %_cmake__builddir'.
> > > 
> > > mkdir -p решает эту проблему в 99.999% случаев (теоретически
> > > возможно, что BUILD — это файл или используетс апстримом для иных
> > > нужд, но на практике такое вряд ли встречается).
> > 
> > Я встречал 2 раза, это уже больше, чем 0.001%. :)
> 
> И 2 пакета, это повод ломать более сотни? По-моему, проще и
> правильнее решить проблему в этой паре пакетов и для остальных
> оставить как есть.
>  
> > Например, в проектах на google c++-стеке встречаются сборочные скрипты
> > для Bazel, точка входа в которые называется именно BUILD.
> > 
> > В одном пакете я даже видел ln -s build BUILD.
> [...] 
> > > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > > ты создал очень даже практическую проблему лишнего уровня
> > > абстракции и реальной поломки сотен пакетов.
> > 
> > Откуда же там сотни?
> > specs% git grep '%cmake_build [A-Z_a-z]' | wc  
> >      45      96    2162
> > Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.
> 
> Откуда циферки?

По странице на альтвики:

%cmake_build VERBOSE=1 сломалось, и вообще любая передача make-флагов
сломалась. Правда, передача произвольных make-флагов была нужна только
в очень малом числе пакетов, которые все были исправлены вчера же. Как
выяснилось, эти make-флаги были не нужны либо ни одному из них, либо
только одному (имя пакета не помню, там передавали RUBY="ruby
-rvendor-specific", но, судя по всему, эту переменную окружения никто не
читал; я передал её на всякий случай как переменную окружения).
Видимо, апстримы переезжали на CMake в какой-то момент, и makeflags были
нужны до переезда.

%cmake_build t1 t2 t3 сломалось, потому что cmake --build принимает
имена целей после -t/--target.

Выражение выше вполне отражает эти два случая.

> 
> $ git grep %cmake_build | wc -l
> 446
> 
> Потенциально сломаны они все.

Сегодня же была тестовая пересборка сизифа, там меньше.

> 
> Best regards,
> Andrew Savchenko



> _______________________________________________
> Devel mailing list
> Devel на lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 833 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20210531/9bd212eb/attachment.bin>