On Mon, Jan 11, 2021 at 10:41:00PM +0100, Konstantin Lepikhov wrote: > Hi Arseny! > > On 01/11/2021, at 07:38:51 PM you wrote: > > > > > а так ли нужны все эти приседания с версиями и rc? У нас же не daily > > > builds собираются. > > > > До поры до времени. > > Начинать готовить адаптацию спека лучше с каких-то достаточно поздних > > rc, особенно в случае, когда после выхода времени у мейнтейнера мало, а > > чуть раньше — много. > а мы куда то спешим? Самая важная причина, по которой я начал миграцию llvm в собственный префикс — в том, что разным пакетам, в т. ч. пакетам-тулчейнам, требуются llvm разной мажорной версии в одном репозитории, потому что они написаны с расчётом на конкретную мажорную версию, и в том, что пользователи не-мейнтейнеры хотели бы иметь в репозитории свежий clang и иногда старый clang. Я не планирую сборку rc в репозиторий, но вот test-only задания — почему нет, если так будет удобно. > > > > > > > > > > +%global llvm_name llvm%v_majmin > > > > +%global clang_name clang%v_majmin > > > > +%global clangd_name clangd%v_majmin > > > > +%global lld_name lld%v_majmin > > > т.е. планируется собирать раздельные версии clang/llvm/lld? на всякий случай уточню: я понял эти слова так, что в репозитории могут сосуществовать clang-11, clang-12 и clang-10, lld-11, lld-12 и lld-10, и да, разные мажорные версии собираются не из одного исходного пакета. > > > > не в рамках одного исходного пакета. > Я знаю, что в Fedora/Arch так делают, поэтому и спросил. Еще у нас есть > lav@ который собирает все что находит - > > https://bugzilla.altlinux.org/show_bug.cgi?id=33411 > https://bugzilla.altlinux.org/show_bug.cgi?id=34672 > > Тут все еще есть нерешенная проблема - чего мы хотим достигнуть с llvm в > сизифе? Конкурентный toolchain или еще одну библиотеку для сборки пакета > xyz. И то, и другое. И не только тулчейн, там ещё много всего интересного. > > > > > <...> > > > > > > %def_disable tests > > > > %ifarch x86_64 aarch64 > > > > %def_without clang > > > почему? without_clang используется только если у нас bootstrap. Иначе > > > будет сборка без LTO. > > > > Внимательно посмотрите changelog и архив. > > > > Одна из возможных причин: > > http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.git;a=commit;h=4b3c6c13e4d70fd201691c636d57b5b020e00709 > > Надо думать, что с этим делать. > Наверное, уведомить апстрим? > > Еще неплохо прояснить вот этот баг > https://bugzilla.altlinux.org/show_bug.cgi?id=34672 _Лично мне_ libcxx не слишком интересна до тех пор, пока с ней не будет иметь смысл собирать (асимптотически) всё, что ныне может быть собрано с libstdc++, и держать такие пакеты в рамках одной инсталляции ОС. Когда-то clang вообще не конкурировал с gcc на том, что ещё пока принято называть гнулинуксами; сейчас, в общем, монокультуры уже нет. О подробностях и прогнозах тут не буду. (Вскользь припомню только недавний порыв пассионарных googlers добавить под зонтик llvm ещё и собственную libc, от чего их отговорило сообщество musl. А где libc, там и elfutils, и dynamic linker.) Собирать её в рамках llvm-экосистемы в репозитории и брать ответственность за её работоспособность _лично я_ точно не в силах и не хочу; если только договориться с теми, кому она нужна. > > > разве тут что-то неверно? > > старый description был слишком неточным и подходил к нескольким бинарным > > пакетам. > по мне масло маслянное ну да ладно. > > > > > Почему нам нужны все TARGETS? > > > > Я скоро буду собирать пакеты, которые этим будут пользоваться. > > > > Ну, и для "clang -target aarch64-unknown-linux-gnu" какого-нибудь. > все таргеты это время сборки, потенциально сваленные тесты и т.д. Более > того, предлагается все эти таргеты поддерживать? В рамках того, что умеет их апстрим. В случае необходимости бутстрапа можно решить собирать только host, а потом им собирать all. > > > Вот тут написано, почему man1dir не лишний: > > > > > > +# Symlink man pages to the man dirs. > > > > +for mand in %buildroot%llvm_datadir/man/man*; do > > > > + mand_index="${mand##*/man}" > > > > + for m in "$mand"/*.[1-9]*; do > > > > + # Let's force compress the man page, then symlink it. > > > > + # /usr/lib/llvm-11.0/share/man/manD/utilX.D.xz -> /usr/share/man/manD/utilX-11.D.xz > > > > + # Otherwise, brp-alt(compress) keeps fucking us up. > > > > + # It remakes the symlinks first, then compresses their targets, > > > > + # severing the symlinks. > > > > + /usr/lib/rpm/compress_files "$m" > > > > + > > > > + mb="$(basename "$m")" # e. g. llvm-ar.1.xz > > > > + new_mb="${mb%%.[1-9]*}-%v_major.$mand_index" # e. g. llvm-ar-11.1.xz > > > > + > > > > + mkdir -p "%buildroot%_mandir/man$mand_index" > > > > + ln -srv "$m" "%buildroot%_mandir/man$mand_index/$new_mb" > > > > + done > > > > +done > Ну так костыль жеж. У нас тут есть мантейнеры rpm, почему они не помогают? > :) Помогут — уберём. :) А пока — надо было достичь готового пакета с удовлетворительным (а лучше — хорошим) результатом; это лучше, чем полгода искать время подготовить исправление и проталкивать его ещё 9 месяцев. Со слов автора /usr/lib/rpm/compress_files, этот старый код надо как-нибудь познакомить с xz и zstd, а то и переосмыслить. > > > > man не смотрит в llvm_man1dir. > > Заморочиться и научить — вариант хуже, чем текущий, потому что программе > > man надо ещё ман от правильной версии достать. > я понимаю ваше желание сделать все красиво, но этот пакет могут > поддерживать другие люди и хотелось бы, чтобы эта поддержка была вот без (Note to self: мне надо бы подробно расписать в каком-то публичном месте, что делает пакет llvm-common, как и зачем, как раз для других людей и приравненного к ним будущего себя.) У себя в packages я подробно веду git-историю всего, что происходит со спеком, с пояснением, почему. Правда, её не видно в git.altlinux.org/srpms... В самом спеке около каждого дредноута я кратко пишу, зачем он. Надо бы собирать из gear, но с использованием апстримных тарболлов, без мучительной перепаковки. В инструментарии gear у нас есть gear-import, а вот, например, такого нет: tar.xz clang name=clang-@version@.src origin=https://github.com/llvm/llvm-project/releases/download/llvmorg-@version@/clang-@version@.src.tar.xz Тогда gear мог бы взять локально закешированный тарболл, выкачанный оттуда, и при составлении исходного пакета его использовать. При этом тарболл распакован в git-репозиторий, с каталогом можно работать средствами git. > таких объездов, особенно, если тут есть те, кто могут помочь и исправить > rpm/gear/whatever. > > PS До сих пор собираю новую версию postfix вот именно из-за таких > прекрасных патчей и .spec которые, конечно, собирают в результате > космический дрендноут, но уж очень неподдерживаемые. Я где-то краем уха слышал, что мейнтейнеры сами недовольны сложившейся ситуацией, но забрасывать дрындноут не готовы, и ребейзить его тоже некогда. > > PPS Огромное спасибо вам, что не бросаете работу и таки собрали пакет! :)