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