[devel] LLVM 11, поддержка нескольких llvm в репозитории

[devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

Господа!

Несколько часов назад вышел LLVM 11.

On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
> <...> LLVM нужно переделывать,

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

> чтобы можно было держать несколько версий одновременно (как
> gcc), на это нужно время и желание, которого пока не накопилось.

Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
симлинками на исполнимые файлы и маны. llvm = %EVR и прочие провайды без
номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
/usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
создавать лишних волнений в чужих пакетах раньше времени — кто собирался
с llvm, clang, lld, по-прежнему получат свою десяточку.
Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
не надо — но кто-то может и не согласиться.

From: "Girar awaiter (arseny)" <girar-builder@altlinux.org>
Subject: [#259819] TESTED srpm=llvm11.0-11.0.0-alt1.src.rpm

On Tue, Oct 13, 2020 at 11:29:26AM +0000, Girar awaiter (arseny) wrote:
> http://git.altlinux.org/tasks/259819/logs/events.1.1.log
> 
> subtask  name      aarch64     armh     i586  ppc64le  x86_64
>    #100  llvm11.0    29:16  2:24:43  1:50:48  2:07:34   41:44
>  
> 2020-Oct-13 08:28:13 :: test-only task #259819 for sisyphus started by arseny:
> <...>
> 2020-Oct-13 11:29:26 :: task #259819 for sisyphus TESTED

В связи с этим несколько вопросов TWIMC:
— нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
  пусть они так и смотрят на llvm10.0 до EOL этого пакета?
— мейнтейнерам пакетов-пользователей LLVM/Clang на CMake:
  сейчас модули упакованы в /usr/lib/llvm-11.0/{%_lib,share}/cmake/.
  Это вообще принципиально с точки зрения удобства сопровождения? Или
  лучше в /usr/{%_lib,share}/cmake куда-то класть? Или как-то ещё? У
  меня этих сведений и соображений на этот счёт скорее нет, а у господ
  мейнтейнеров, наверное, есть.
— нужна ли LLVM Packaging Policy?

Другие конструктивные комментарии приветствуются. Если никто не будет
возражать, между этой пятницей и следующим вторником пакет полетит в
сизиф.

Как из спека llvm10 получился спек llvm11, можно посмотреть тут[1].
[1] http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.0rc6.git

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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Aleksei Nikiforov]

13.10.2020 16:07, Arseny Maslennikov пишет:
> Господа!
> 
> Несколько часов назад вышел LLVM 11.

...

> — мейнтейнерам пакетов-пользователей LLVM/Clang на CMake:
>    сейчас модули упакованы в /usr/lib/llvm-11.0/{%_lib,share}/cmake/.
>    Это вообще принципиально с точки зрения удобства сопровождения? Или
>    лучше в /usr/{%_lib,share}/cmake куда-то класть? Или как-то ещё? У
>    меня этих сведений и соображений на этот счёт скорее нет, а у господ
>    мейнтейнеров, наверное, есть.

Упаковка файлов cmake по нестандартным путям точно вызовет проблемы и 
необходимость адаптации всех использующих их при сборке пакетов:

https://bugzilla.altlinux.org/38660

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 4157 bytes --]

13.10.2020 16:07, Arseny Maslennikov пишет:
> Господа!
> 
> Несколько часов назад вышел LLVM 11.
> 
> On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
>> <...> LLVM нужно переделывать,
> 
> Сие в меру знаменательное событие стало неплохим поводом для того,
> чтобы начать переделывать упаковку LLVM в сизифе.
> 
>> чтобы можно было держать несколько версий одновременно (как
>> gcc), на это нужно время и желание, которого пока не накопилось.
> 
> Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> симлинками на исполнимые файлы и маны.

бессмысленное занятие. я уже не раз планировал это сделать, но апстим не
предполагает установку нескольких версий одновременно. хотя попробуй,
может у тебя что нибудь путное получится

> llvm = %EVR и прочие провайды без
> номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
> /usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
> создавать лишних волнений в чужих пакетах раньше времени — кто собирался
> с llvm, clang, lld, по-прежнему получат свою десяточку.
> Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
> не надо — но кто-то может и не согласиться.
> 
> From: "Girar awaiter (arseny)" <girar-builder@altlinux.org>
> Subject: [#259819] TESTED srpm=llvm11.0-11.0.0-alt1.src.rpm
> 
> On Tue, Oct 13, 2020 at 11:29:26AM +0000, Girar awaiter (arseny) wrote:
>> http://git.altlinux.org/tasks/259819/logs/events.1.1.log
>>
>> subtask  name      aarch64     armh     i586  ppc64le  x86_64
>>    #100  llvm11.0    29:16  2:24:43  1:50:48  2:07:34   41:44
>>  
>> 2020-Oct-13 08:28:13 :: test-only task #259819 for sisyphus started by arseny:
>> <...>
>> 2020-Oct-13 11:29:26 :: task #259819 for sisyphus TESTED
> 
> В связи с этим несколько вопросов TWIMC:
> — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
>   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
> — мейнтейнерам пакетов-пользователей LLVM/Clang на CMake:
>   сейчас модули упакованы в /usr/lib/llvm-11.0/{%_lib,share}/cmake/.
>   Это вообще принципиально с точки зрения удобства сопровождения? Или
>   лучше в /usr/{%_lib,share}/cmake куда-то класть? Или как-то ещё? У
>   меня этих сведений и соображений на этот счёт скорее нет, а у господ
>   мейнтейнеров, наверное, есть.
> — нужна ли LLVM Packaging Policy?
> 
> Другие конструктивные комментарии приветствуются. Если никто не будет
> возражать, между этой пятницей и следующим вторником пакет полетит в
> сизиф.
> 
> Как из спека llvm10 получился спек llvm11, можно посмотреть тут[1].
> [1] http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.0rc6.git
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 


-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Michael Shigorin]

On Tue, Oct 13, 2020 at 04:07:59PM +0300, Arseny Maslennikov wrote:
> > чтобы можно было держать несколько версий одновременно (как gcc)
> Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0

А зачем?  Для Mesa в любом случае нужна довольно жёстко
привязанная "своя" версия, насколько до сих пор понял.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Vitaly Lipatov]

Arseny Maslennikov писал 13.10.20 16:07:
> Господа!
> 
> Несколько часов назад вышел LLVM 11.
> 
> On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
>> <...> LLVM нужно переделывать,
> 
> Сие в меру знаменательное событие стало неплохим поводом для того,
> чтобы начать переделывать упаковку LLVM в сизифе.
> 
>> чтобы можно было держать несколько версий одновременно (как
>> gcc), на это нужно время и желание, которого пока не накопилось.
А зачем это нужно, держать несколько llvm?
Какие есть use cases?

> В связи с этим несколько вопросов TWIMC:
> — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? 
> Или
>   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
Мне кажется правильным смотреть на «как gcc», то есть нужна возможность 
запустить llvm, clang.

> — мейнтейнерам пакетов-пользователей LLVM/Clang на CMake:
>   сейчас модули упакованы в /usr/lib/llvm-11.0/{%_lib,share}/cmake/.
>   Это вообще принципиально с точки зрения удобства сопровождения? Или
>   лучше в /usr/{%_lib,share}/cmake куда-то класть? Или как-то ещё? У
>   меня этих сведений и соображений на этот счёт скорее нет, а у господ
>   мейнтейнеров, наверное, есть.
Правильно это класть туда, где cmake сможет найти. Но это идёт вразрез с 
идей установки нескольких llvm, если только не вынести модули cmake в 
отдельный конфликтующий пакет.

Ссылку на нерешённую багу Алексей уже привёл:
https://bugzilla.altlinux.org/38660

Ваша сборка должна закрывать эту багу, мне кажется.

> — нужна ли LLVM Packaging Policy?
Конечно!

> Другие конструктивные комментарии приветствуются. Если никто не будет
> возражать, между этой пятницей и следующим вторником пакет полетит в
> сизиф.
> 
> Как из спека llvm10 получился спек llvm11, можно посмотреть тут[1].
> [1] http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.0rc6.git
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

On Tue, Oct 13, 2020 at 05:02:35PM +0300, Vitaly Lipatov wrote:
> Arseny Maslennikov писал 13.10.20 16:07:
> > Господа!
> > 
> > Несколько часов назад вышел LLVM 11.
> > 
> > On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
> > > <...> LLVM нужно переделывать,
> > 
> > Сие в меру знаменательное событие стало неплохим поводом для того,
> > чтобы начать переделывать упаковку LLVM в сизифе.
> > 
> > > чтобы можно было держать несколько версий одновременно (как
> > > gcc), на это нужно время и желание, которого пока не накопилось.
> А зачем это нужно, держать несколько llvm?
> Какие есть use cases?

Проект LLVM между мажорными выпусками, которые у него теперь раз в
полгода, ломает любую обратную совместимость, которую считает нужным, и
полагает, что пользователи завязываются на конкретную мажорную версию.
Взгляните ради интереса на усилия по ссылкам, что людям приходится
делать, чтобы уйти от одного мажорного LLVM на другой.
Пользователи LLVM шевелятся с разной скоростью, и у наших пакетов могут
быть совершенно разные зависимости даже на конкретные версии этих
пользователей, и в будущем, скорее всего, будет только сложнее.

[1] https://github.com/ziglang/zig/commit/41a8b6f57b3bd50b2ed6fdced74fba9130eac3d3
[2] https://github.com/ziglang/zig/commit/bd121f3af46bc22a25ac0495e8d83461510c77d4
[3] https://github.com/ziglang/zig/commit/cd91e17b7384fe857c5cf847b106cd0f98cb4d6a
[4] https://github.com/ziglang/zig/commit/c8ea8cf5df8261995b1e451085e39cd612c9e038
[5] https://github.com/ziglang/zig/commit/4053b95d8e2dea661ff7b1dfdb4a9aa32d08db14
[6] https://github.com/rust-lang/rust/pull/73525/
[7] https://github.com/rust-lang/rust/pull/73526/
Rust так вообще уже неделю как в вашем кинотеатре, выше головы прыгнул. :)

Ссылки решительно не исчерпывающие.

> 
> > В связи с этим несколько вопросов TWIMC:
> > — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
> >   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
> Мне кажется правильным смотреть на «как gcc», то есть нужна возможность
> запустить llvm, clang.

OK. Тогда чуть позже, но до LLVM 12, возможность запустить
/usr/bin/clang появится.
Пока что она есть, если поставить в окружение десятку.

Про произвольные llvm-утилиты — вот тут даже я задумался, насколько это
востребовано... но от введения их поддержки реализация llvm-util-wrapper
сильно не усложнится.

> 
> > — мейнтейнерам пакетов-пользователей LLVM/Clang на CMake:
> >   сейчас модули упакованы в /usr/lib/llvm-11.0/{%_lib,share}/cmake/.
> >   Это вообще принципиально с точки зрения удобства сопровождения? Или
> >   лучше в /usr/{%_lib,share}/cmake куда-то класть? Или как-то ещё? У
> >   меня этих сведений и соображений на этот счёт скорее нет, а у господ
> >   мейнтейнеров, наверное, есть.
> Правильно это класть туда, где cmake сможет найти. Но это идёт вразрез с
> идей установки нескольких llvm, если только не вынести модули cmake в
> отдельный конфликтующий пакет.
> 
> Ссылку на нерешённую багу Алексей уже привёл:
> https://bugzilla.altlinux.org/38660
> 
> Ваша сборка должна закрывать эту багу, мне кажется.

Или ещё не закрывает; надо убедиться.

> 
> > — нужна ли LLVM Packaging Policy?
> Конечно!

Тогда постараюсь вскоре набросать прототип.

> 
> > Другие конструктивные комментарии приветствуются. Если никто не будет
> > возражать, между этой пятницей и следующим вторником пакет полетит в
> > сизиф.
> > 
> > Как из спека llvm10 получился спек llvm11, можно посмотреть тут[1].
> > [1] http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.0rc6.git
> > 
> > _______________________________________________
> > Devel mailing list
> > Devel@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/devel
> 
> -- 
> С уважением,
> Виталий Липатов,
> ALT Linux Team
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

On Tue, Oct 13, 2020 at 05:02:35PM +0300, Vitaly Lipatov wrote:
> Arseny Maslennikov писал 13.10.20 16:07:
> > — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
> >   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
> Мне кажется правильным смотреть на «как gcc», то есть нужна возможность
> запустить llvm, clang.
> 

Но мой вопрос был про Provides: llvm = %EVR. Я пока убеждён, что при
нумерованной упаковке LLVM такие пакеты в целом не нужны, и от них надо
постепенно уходить; либо каким-то неведомым мне или неформализуемым
образом решать, что новая версия llvm годится как stable sane choice, и
добавлять этот провайд.

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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

On Tue, Oct 13, 2020 at 04:40:59PM +0300, Валерий Иноземцев wrote:
> 13.10.2020 16:07, Arseny Maslennikov пишет:
> > Господа!
> > 
> > Несколько часов назад вышел LLVM 11.
> > 
> > On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
> >> <...> LLVM нужно переделывать,
> > 
> > Сие в меру знаменательное событие стало неплохим поводом для того,
> > чтобы начать переделывать упаковку LLVM в сизифе.
> > 
> >> чтобы можно было держать несколько версий одновременно (как
> >> gcc), на это нужно время и желание, которого пока не накопилось.
> > 
> > Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> > симлинками на исполнимые файлы и маны.
> 
> бессмысленное занятие. я уже не раз планировал это сделать, но апстим не
> предполагает установку нескольких версий одновременно. хотя попробуй,
> может у тебя что нибудь путное получится

Я пока уверен, что получится =) У Debian, как минимум, получилось.
Рач и федора не пытаются, но они и не брезгуют искусственными
ограничениями на пакеты и вообще мало интересуются качеством и ценностью
пакетов, у них другие цели.


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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

On Tue, Oct 13, 2020 at 05:00:55PM +0300, Michael Shigorin wrote:
> On Tue, Oct 13, 2020 at 04:07:59PM +0300, Arseny Maslennikov wrote:
> > > чтобы можно было держать несколько версий одновременно (как gcc)
> > Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0
> 
> А зачем?  Для Mesa в любом случае нужна довольно жёстко
> привязанная "своя" версия, насколько до сих пор понял.

Я вообще не в курсе про нужды Mesa, пусть про неё подумают и поделятся
те, кто разбирается лучше.
Для этого отчасти притащил lakostis@ в To:.

На общий же вопрос "зачем" предостаточно ответов в этом треде, и даже не
только в этом — они ищутся при помощи grep -i "llvm" по сабжам писем
рассылки.


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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Vitaly Lipatov]

Arseny Maslennikov писал 13.10.20 18:51:
> On Tue, Oct 13, 2020 at 05:02:35PM +0300, Vitaly Lipatov wrote:
>> Arseny Maslennikov писал 13.10.20 16:07:
>> > — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
>> >   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
>> Мне кажется правильным смотреть на «как gcc», то есть нужна 
>> возможность
>> запустить llvm, clang.
>> 
> 
> Но мой вопрос был про Provides: llvm = %EVR. Я пока убеждён, что при
> нумерованной упаковке LLVM такие пакеты в целом не нужны, и от них надо
+1

> постепенно уходить; либо каким-то неведомым мне или неформализуемым
> образом решать, что новая версия llvm годится как stable sane choice, и
> добавлять этот провайд.
+1

Для тех, кому не важно, какая версия, такой provide должен быть. 
Например, мне надо что-то собрать, и делаю
apt-get install gcc
или
apt-get install clang
и меня не волнуют версии.
Это уровень пользователя.

При сборке пакета, напротив, мантейнер пакета решает, какая версия clang 
подходит пакету, и должен выставлять тогда нумерованный Requires:

Собственно, тогда на уровне макросов должно быть лёгкое управление, 
какой clang будет использоваться. Как это сделано для gcc 
(%set_gcc_version).

Идею неформальным образом решать, какая версия llvm будет stable sane 
choice, очень поддерживаю.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Vitaly Lipatov]

Arseny Maslennikov писал 13.10.20 18:42:
...
> Проект LLVM между мажорными выпусками, которые у него теперь раз в
> полгода, ломает любую обратную совместимость, которую считает нужным, и
> полагает, что пользователи завязываются на конкретную мажорную версию.
> Взгляните ради интереса на усилия по ссылкам, что людям приходится
> делать, чтобы уйти от одного мажорного LLVM на другой.
> Пользователи LLVM шевелятся с разной скоростью, и у наших пакетов могут
> быть совершенно разные зависимости даже на конкретные версии этих
> пользователей, и в будущем, скорее всего, будет только сложнее.
Что в репозитории для сборки пакетов нужны разные версии llvm, теперь 
стало понятно. И не оспаривается. Но так ли необходимо при этом 
обеспечивать одновременную установку в систему?
Просто если это слишком сложно в реализации (и особенно создаст потом 
сплошные проблемы), надо точно понимать, что это кому-то нужно.

> Про произвольные llvm-утилиты — вот тут даже я задумался, насколько это
> востребовано... но от введения их поддержки реализация 
> llvm-util-wrapper
> сильно не усложнится.
Наверное, достаточно, чтобы был и работал clang/clang++ ?

...
>> Правильно это класть туда, где cmake сможет найти. Но это идёт вразрез 
>> с
>> идей установки нескольких llvm, если только не вынести модули cmake в
>> отдельный конфликтующий пакет.
>> 
>> Ссылку на нерешённую багу Алексей уже привёл:
>> https://bugzilla.altlinux.org/38660
>> 
>> Ваша сборка должна закрывать эту багу, мне кажется.
> 
> Или ещё не закрывает; надо убедиться.
Я имел в виду, что нужно придумать решение, которое не будет приводить к 
этой баге :)
Если сохранить возможность соустановки нескольких clang, то тогда 
придётся cmake-модули выносить в отдельные конфликтующие пакеты. Или ещё 
можно предлагать расширять путь поиска модулей cmake, что странно.

...

>> > Другие конструктивные комментарии приветствуются. Если никто не будет
>> > возражать, между этой пятницей и следующим вторником пакет полетит в
>> > сизиф.
>> >
>> > Как из спека llvm10 получился спек llvm11, можно посмотреть тут[1].
>> > [1] http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.0rc6.git
Как я понимаю, если он не ломает llvm10, почему бы не полететь :)

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Konstantin Lepikhov]

Hi Arseny!

On 10/13/2020, at 04:07:59 PM you wrote:

> Господа!
> 
> Несколько часов назад вышел LLVM 11.
И все должны сразу понять, что наступило ОНО?

> 
> On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
> > <...> LLVM нужно переделывать,
> 
> Сие в меру знаменательное событие стало неплохим поводом для того,
> чтобы начать переделывать упаковку LLVM в сизифе.
> 
> > чтобы можно было держать несколько версий одновременно (как
> > gcc), на это нужно время и желание, которого пока не накопилось.
> 
> Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> симлинками на исполнимые файлы и маны. llvm = %EVR и прочие провайды без
> номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
> /usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
> создавать лишних волнений в чужих пакетах раньше времени — кто собирался
> с llvm, clang, lld, по-прежнему получат свою десяточку.
> Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
> не надо — но кто-то может и не согласиться.
Я не понял из этого описания, что именно предлагается сделать? Собрать
llvm11 "не как всегда" и на этом успокоиться?

> 
> From: "Girar awaiter (arseny)" <girar-builder@altlinux.org>
> Subject: [#259819] TESTED srpm=llvm11.0-11.0.0-alt1.src.rpm
> 
> On Tue, Oct 13, 2020 at 11:29:26AM +0000, Girar awaiter (arseny) wrote:
> > http://git.altlinux.org/tasks/259819/logs/events.1.1.log
> > 
> > subtask  name      aarch64     armh     i586  ppc64le  x86_64
> >    #100  llvm11.0    29:16  2:24:43  1:50:48  2:07:34   41:44
> >  
> > 2020-Oct-13 08:28:13 :: test-only task #259819 for sisyphus started by arseny:
> > <...>
> > 2020-Oct-13 11:29:26 :: task #259819 for sisyphus TESTED
> 
> В связи с этим несколько вопросов TWIMC:
> — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
>   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
llvm это не toolchain, это framework для создания своего toolchain. В
первую очередь нужно огласить аудиторию, для кого это делается и зачем.
Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.

На текущий момент в сизифе есть только 2 пользователя пакета clang - это
firefox (частично) и chromium, mesa не в счет поскольку адекватного
объяснения зачем до сир пор не прозвучало. Остальные проекты носят llvm с
собой (например amdvlk) и собраны с ним (блобы nvidia).

> — мейнтейнерам пакетов-пользователей LLVM/Clang на CMake:
>   сейчас модули упакованы в /usr/lib/llvm-11.0/{%_lib,share}/cmake/.
>   Это вообще принципиально с точки зрения удобства сопровождения? Или
>   лучше в /usr/{%_lib,share}/cmake куда-то класть? Или как-то ещё? У
>   меня этих сведений и соображений на этот счёт скорее нет, а у господ
>   мейнтейнеров, наверное, есть.
Главное не куда клать, а сделать так, чтобы потом этими cmake'ами можно
было пользоваться т.к. флаги и пути могут измениться.

> — нужна ли LLVM Packaging Policy?
Кому нужна?

> 
> Другие конструктивные комментарии приветствуются. Если никто не будет
> возражать, между этой пятницей и следующим вторником пакет полетит в
> сизиф.
Мы куда-то спешим, что сразу ставятся сроки и размахивания шашкой?

> 
> Как из спека llvm10 получился спек llvm11, можно посмотреть тут[1].
> [1] http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.0rc6.git
Приведите полную ссылку на diff относительно текущей конфигурации пожалуйста.

PS Меньше пафоса больше дела.

-- 
WBR et al.

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Andrey Savchenko]

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

On Wed, 14 Oct 2020 11:41:00 +0200 Konstantin Lepikhov wrote:
> llvm это не toolchain, это framework для создания своего toolchain. В
> первую очередь нужно огласить аудиторию, для кого это делается и зачем.
> Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.
> 
> На текущий момент в сизифе есть только 2 пользователя пакета clang - это
> firefox (частично) и chromium, mesa не в счет поскольку адекватного
> объяснения зачем до сир пор не прозвучало. Остальные проекты носят llvm с
> собой (например amdvlk) и собраны с ним (блобы nvidia).

Не пишите ерунду. В mesa LLVM необходим для работы gallium на ряде
большинстве чипов Radeon. Он используется как минимум при
компиляции шейдеров данными драйверами.

> PS Меньше пафоса больше дела.

Вот-вот, начните с себя, Константин.

Best regards,
Andrew Savchenko

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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Konstantin Lepikhov]

Hi Andrey!

On 10/14/2020, at 01:20:20 PM you wrote:

> On Wed, 14 Oct 2020 11:41:00 +0200 Konstantin Lepikhov wrote:
> > llvm это не toolchain, это framework для создания своего toolchain. В
> > первую очередь нужно огласить аудиторию, для кого это делается и зачем.
> > Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.
> > 
> > На текущий момент в сизифе есть только 2 пользователя пакета clang - это
> > firefox (частично) и chromium, mesa не в счет поскольку адекватного
> > объяснения зачем до сир пор не прозвучало. Остальные проекты носят llvm с
> > собой (например amdvlk) и собраны с ним (блобы nvidia).
> 
> Не пишите ерунду. В mesa LLVM необходим для работы gallium на ряде
> большинстве чипов Radeon. Он используется как минимум при
> компиляции шейдеров данными драйверами.
>
LLVM как библиотека, а не toolchain. Как toolchain он там нужен только для
clover, который не нужен.

-- 
WBR et al.

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Vladimir D. Seleznev]

On Wed, Oct 14, 2020 at 11:41:00AM +0200, Konstantin Lepikhov wrote:
> Hi Arseny!
> 
> On 10/13/2020, at 04:07:59 PM you wrote:
> 
> > Господа!
> > 
> > Несколько часов назад вышел LLVM 11.
> И все должны сразу понять, что наступило ОНО?
> 
> > 
> > On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
> > > <...> LLVM нужно переделывать,
> > 
> > Сие в меру знаменательное событие стало неплохим поводом для того,
> > чтобы начать переделывать упаковку LLVM в сизифе.
> > 
> > > чтобы можно было держать несколько версий одновременно (как
> > > gcc), на это нужно время и желание, которого пока не накопилось.
> > 
> > Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> > симлинками на исполнимые файлы и маны. llvm = %EVR и прочие провайды без
> > номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
> > /usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
> > создавать лишних волнений в чужих пакетах раньше времени — кто собирался
> > с llvm, clang, lld, по-прежнему получат свою десяточку.
> > Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
> > не надо — но кто-то может и не согласиться.
> Я не понял из этого описания, что именно предлагается сделать? Собрать
> llvm11 "не как всегда" и на этом успокоиться?
> 
> > 
> > From: "Girar awaiter (arseny)" <girar-builder@altlinux.org>
> > Subject: [#259819] TESTED srpm=llvm11.0-11.0.0-alt1.src.rpm
> > 
> > On Tue, Oct 13, 2020 at 11:29:26AM +0000, Girar awaiter (arseny) wrote:
> > > http://git.altlinux.org/tasks/259819/logs/events.1.1.log
> > > 
> > > subtask  name      aarch64     armh     i586  ppc64le  x86_64
> > >    #100  llvm11.0    29:16  2:24:43  1:50:48  2:07:34   41:44
> > >  
> > > 2020-Oct-13 08:28:13 :: test-only task #259819 for sisyphus started by arseny:
> > > <...>
> > > 2020-Oct-13 11:29:26 :: task #259819 for sisyphus TESTED
> > 
> > В связи с этим несколько вопросов TWIMC:
> > — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
> >   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
> llvm это не toolchain, это framework для создания своего toolchain. В
> первую очередь нужно огласить аудиторию, для кого это делается и зачем.
> Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.

Я так понял, у участников сообщества возник интерес заниматься проектами
экспериментальных языков программирования и их тулчейнами, такими как
crystal и ziglang, каждому из которых нужна определённая версия LLVM
(замечу, что в Сизифе уже есть как минимум rust из пользователей LLVM).
Для того, чтобы не бундлить её в каждый из этих проектов, Арсений
предложил вышеизложенную схему.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Konstantin Lepikhov]

Hi Vladimir!

On 10/14/2020, at 02:56:37 PM you wrote:

<skip>
> > llvm это не toolchain, это framework для создания своего toolchain. В
> > первую очередь нужно огласить аудиторию, для кого это делается и зачем.
> > Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.
> 
> Я так понял, у участников сообщества возник интерес заниматься проектами
> экспериментальных языков программирования и их тулчейнами, такими как
> crystal и ziglang, каждому из которых нужна определённая версия LLVM
> (замечу, что в Сизифе уже есть как минимум rust из пользователей LLVM).
"особая версия" это major number или snapshot с нашими вкусными патчами?
Google Chrome собирается llvm/clang со вкусом google, но это не значит что
нужно тащить этот llvm в сизиф, потому что у нас есть chromium и его
гипотетически можно таким llvm собрать. Нет ничего плохого в собирании проекта со
своим llvm, если на это есть причина (как, например, для amdvlk), а вот
поддерживать потом этот зоопарк только ради красивой идеи как-то
бессмысленно.

> Для того, чтобы не бундлить её в каждый из этих проектов, Арсений
> предложил вышеизложенную схему.
> 
Схема жизнеспособна только в определенных случаях.

-- 
WBR et al.

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

On Wed, Oct 14, 2020 at 11:41:00AM +0200, Konstantin Lepikhov wrote:
> Hi Arseny!
> 
> On 10/13/2020, at 04:07:59 PM you wrote:
> 
> > Господа!
> > 
> > Несколько часов назад вышел LLVM 11.

Так и знал, что кто-то будет язвить.
Здесь должно было быть написано "со дня на день выходит LLVM 11", но я
протормозил с заданием и с этим письмом.

> И все должны сразу понять, что наступило ОНО?

Не знаю, кто что кому должен.

Ваш вопрос в том, почему я "так рано" об этом заговорил? Потому что рано
начать думать и советоваться с сообществом — не значит рано упаковать и
начать пользоваться. Напротив, получается больше времени, чтобы сделать
хорошо.

Начал я эту сборку готовить во время rc4-rc5 где-то, когда время было, а
во вторник отребейзил c rc6. rc6 оказался идентичен релизу, кроме имён
каталогов в релизном тарболле.

Более того, при появлении первых 12.0-rc, например, стоит начать
готовить и их к сборке. Тогда и грабли будут собраны (и не попадут в
сизиф), и сильной задержки не будет.

> 
> > 
> > On Tue, Sep 17, 2019 at 10:27:18AM +0200, Konstantin Lepikhov wrote:
> > > <...> LLVM нужно переделывать,
> > 
> > Сие в меру знаменательное событие стало неплохим поводом для того,
> > чтобы начать переделывать упаковку LLVM в сизифе.
> > 
> > > чтобы можно было держать несколько версий одновременно (как
> > > gcc), на это нужно время и желание, которого пока не накопилось.
> > 
> > Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> > симлинками на исполнимые файлы и маны. llvm = %EVR и прочие провайды без
> > номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
> > /usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
> > создавать лишних волнений в чужих пакетах раньше времени — кто собирался
> > с llvm, clang, lld, по-прежнему получат свою десяточку.
> > Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
> > не надо — но кто-то может и не согласиться.
> Я не понял из этого описания, что именно предлагается сделать? Собрать
> llvm11 "не как всегда" и на этом успокоиться?

Нет, конечно, там много других проблем.
Например, надо в сборочный сценарий в спеке добавить stage2.
Подумать, что делать с liblldDriver.a и прочими, которые нужны и в LLVM-IR-объекте
для любителей LLVM ThinLTO, и в нативном объекте для пользователей GNU
toolchain, которые собирают пользователей LLVM.

> 
> > 
> > From: "Girar awaiter (arseny)" <girar-builder@altlinux.org>
> > Subject: [#259819] TESTED srpm=llvm11.0-11.0.0-alt1.src.rpm
> > 
> > On Tue, Oct 13, 2020 at 11:29:26AM +0000, Girar awaiter (arseny) wrote:
> > > http://git.altlinux.org/tasks/259819/logs/events.1.1.log
> > > 
> > > subtask  name      aarch64     armh     i586  ppc64le  x86_64
> > >    #100  llvm11.0    29:16  2:24:43  1:50:48  2:07:34   41:44
> > >  
> > > 2020-Oct-13 08:28:13 :: test-only task #259819 for sisyphus started by arseny:
> > > <...>
> > > 2020-Oct-13 11:29:26 :: task #259819 for sisyphus TESTED
> > 
> > В связи с этим несколько вопросов TWIMC:
> > — нужны ли в будущем вообще провайды без суффикса: llvm, lld, clang? Или
> >   пусть они так и смотрят на llvm10.0 до EOL этого пакета?
> llvm это не toolchain, это framework для создания своего toolchain. В

Даже без clang и flang таких toolchain в вашем смысле сейчас пруд пруди, и,
скорее всего, в будущем будет больше.
flang, кстати, надо собрать будет.

> первую очередь нужно огласить аудиторию, для кого это делается и зачем.
> Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.
> 
> На текущий момент в сизифе есть только 2 пользователя пакета clang - это

% cut -f2 ufb-2 | grep -E '(clang|llvm|lld)10.0' | sort | uniq | LC_COLLATE=C join -11 -22 -o2.1 - ufb-2 | sort | uniq > want-llvm10.0
% wc -l want-llvm10.0 
969 want-llvm10.0

Вот сколько пакетов в сизифе двухнедельной давности хотят
'(clang|llvm|lld)10.0' в BR. Где-то половина из них хочет qt5-tools,
который уже хочет libclang.so. Предложите вендорить весь llvm туда?

В общем месте всех актуальных апстримов всё больше разработчиков
(правда, редко поясняя, почему — и это мне не нравится) отбрасывают gnu
toolchain в пользу clang-based.

> firefox (частично) и chromium, mesa не в счет поскольку адекватного
> объяснения зачем до сир пор не прозвучало.

А ещё люди-разработчики, которых в сизиф, к счастью, не упаковывают. =)
Ни на альтлинукс.орг, ни на гетальт.орг, ни на базеальт.ру не написано,
что альт — не для людей.

> Остальные проекты носят llvm с
> собой (например amdvlk) и собраны с ним (блобы nvidia).

Конечно, будет некоторое меньшинство тех, кто тащит свой llvm с собой,
может быть, патченный, или с собственным бекендом. Но если так будут
делать все — тащить свой llvm и собирать — то треснут или зеркала, или
сборочница. А ещё треснут сетевые каналы обновляющих.

> 
> > — мейнтейнерам пакетов-пользователей LLVM/Clang на CMake:
> >   сейчас модули упакованы в /usr/lib/llvm-11.0/{%_lib,share}/cmake/.
> >   Это вообще принципиально с точки зрения удобства сопровождения? Или
> >   лучше в /usr/{%_lib,share}/cmake куда-то класть? Или как-то ещё? У
> >   меня этих сведений и соображений на этот счёт скорее нет, а у господ
> >   мейнтейнеров, наверное, есть.
> Главное не куда клать, а сделать так, чтобы потом этими cmake'ами можно
> было пользоваться т.к. флаги и пути могут измениться.

Согласен, надо подойти к этому ответственно. Поэтому и задан вопрос.

> 
> > — нужна ли LLVM Packaging Policy?
> Кому нужна?

Вам не нужна, спасибо за мнение.

> 
> > 
> > Другие конструктивные комментарии приветствуются. Если никто не будет
> > возражать, между этой пятницей и следующим вторником пакет полетит в
> > сизиф.
> Мы куда-то спешим, что сразу ставятся сроки и размахивания шашкой?

Уже стало понятно, что раньше будущей недели не надо, да и не выйдет.
Это к слову о "случилось ОНО".

Вашим пакетам это помешает? Или чему-то ещё помешает? Если да, поясните,
чем, буду благодарен, для этого и письмо.
Пока у меня впечатление, что нет: llvm, clang, lld десятые остаются в
репозитории под тем же именем и соустанавливаются с *-11.0.

Зачем мне в репозитории LLVM 11 и вообще релизы LLVM по мере их выхода,
я могу сказать, но это оффтопик, и особо ревнивые личности тут же
откроют филиал LOR и поспешат мне возразить, что ни пакеты, что я
собираю или планирую, не нужны, ни llvm не нужен, ни вообще я не нужен в
сообществе. Проходили уже.
Более того, в этом треде я даже почти проговорился.



> 
> > 
> > Как из спека llvm10 получился спек llvm11, можно посмотреть тут[1].
> > [1] http://git.altlinux.org/people/arseny/packages/?p=llvm11.0.0rc6.git
> Приведите полную ссылку на diff относительно текущей конфигурации пожалуйста.

Ох. Чуть позже приведу.
(в сторону: может, вообще перестать страдать и начать собирать из gear?)

> 
> PS Меньше пафоса больше дела.
> 
> -- 
> WBR et al.

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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

On Wed, Oct 14, 2020 at 02:45:52PM +0200, Konstantin Lepikhov wrote:
> Hi Vladimir!
> 
> On 10/14/2020, at 02:56:37 PM you wrote:
> 
> <skip>
> > > llvm это не toolchain, это framework для создания своего toolchain. В

Который распространяется в виде библиотек, которые далеко не все готовы ещё и
патчить, как мне представляется.

> > > первую очередь нужно огласить аудиторию, для кого это делается и зачем.
> > > Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.
> > 
> > Я так понял, у участников сообщества возник интерес заниматься проектами
> > экспериментальных языков программирования и их тулчейнами, такими как
> > crystal и ziglang, каждому из которых нужна определённая версия LLVM
> > (замечу, что в Сизифе уже есть как минимум rust из пользователей LLVM).
> "особая версия" это major number или snapshot с нашими вкусными патчами?

Major number.
Наши патчи не очень вкусные, кстати; обычные такие дистрибутивные.

> Google Chrome собирается llvm/clang со вкусом google, но это не значит что

А, вы про *их* патчи, извините тогда.

> нужно тащить этот llvm в сизиф, потому что у нас есть chromium и его
> гипотетически можно таким llvm собрать.

А кто-то, кроме Google, собирает Google Chrome? Мы зачем-то упаковываем
блобы, да.
Да и Google — это же денежная сарделька; они при желании могут учредить себе
карманную банановую республику добра, у них уже и суверенный интернет
есть — не то что мейнтейнить собственный LLVM.

> Нет ничего плохого в собирании проекта со
> своим llvm, если на это есть причина (как, например, для amdvlk), а вот
> поддерживать потом этот зоопарк только ради красивой идеи как-то
> бессмысленно.
> 
> > Для того, чтобы не бундлить её в каждый из этих проектов, Арсений
> > предложил вышеизложенную схему.
> > 
> Схема жизнеспособна только в определенных случаях.
> 
> -- 
> WBR et al.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Konstantin Lepikhov]

Hi Arseny!

On 10/14/2020, at 04:49:15 PM you wrote:

<skip>
> > первую очередь нужно огласить аудиторию, для кого это делается и зачем.
> > Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.
обращаю еще раз внимание на это цитирование.

Я собирал llvm/clang в сизиф с определенной целью - собрать firefox и
chromium наиболее оптимально по производительности и мы этого с @legion
добились (не знаю как сейчас). Mesa, которой все почему-то тыкают, можно
прекрасно собрать и со статическим llvm, и с llvm как специализованной
библиотекой причем без всяких lld/clang и даже x86 target'а. Т.е. у меня
была цель и она была озвучена (см. https://www.altlinux.org/LLVM).

Если же вы решили подонкихоствовать и научить мир собирать "правильно", то
удачи. Если же у вас есть план как это сделать, то давайте его обсуждать.

> > 
> > На текущий момент в сизифе есть только 2 пользователя пакета clang - это
> 
> % cut -f2 ufb-2 | grep -E '(clang|llvm|lld)10.0' | sort | uniq | LC_COLLATE=C join -11 -22 -o2.1 - ufb-2 | sort | uniq > want-llvm10.0
> % wc -l want-llvm10.0 
> 969 want-llvm10.0
> 
> Вот сколько пакетов в сизифе двухнедельной давности хотят
> '(clang|llvm|lld)10.0' в BR. Где-то половина из них хочет qt5-tools,
> который уже хочет libclang.so. Предложите вендорить весь llvm туда?
Предлагаю сесть и подумать еще раз. Список выше - это зависимости, которых
может и не быть, если захотеть.

Если вы начали с пафоса и истерики, ожидайте такого же ответа.

-- 
WBR et al.

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Vitaly Lipatov]

Konstantin Lepikhov писал 14.10.20 18:47:
> Hi Arseny!
> 
> On 10/14/2020, at 04:49:15 PM you wrote:
> 
> <skip>
>> > первую очередь нужно огласить аудиторию, для кого это делается и зачем.
>> > Текущий мантейнер llvm вряд ли понимает, зачем он его собирает.
> обращаю еще раз внимание на это цитирование.
> 
> Я собирал llvm/clang в сизиф с определенной целью - собрать firefox и
> chromium наиболее оптимально по производительности и мы этого с @legion
> добились (не знаю как сейчас). Mesa, которой все почему-то тыкают, 
> можно
...
> Если же вы решили подонкихоствовать и научить мир собирать "правильно", 
> то
> удачи. Если же у вас есть план как это сделать, то давайте его 
> обсуждать.
...

Я не очень понимаю, почему нельзя просто иметь в репозитории свежий 
clang? Без отсылок для чего это. Никто не же обосновывает, зачем нам gcc 
в репозитории. Или glibc. Мне вот glibc не нравится.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

[-- Attachment #1.1: Type: text/plain, Size: 475 bytes --]

On Wed, Oct 14, 2020 at 11:41:00AM +0200, Konstantin Lepikhov wrote:
> Hi Arseny!
> 
> Приведите полную ссылку на diff относительно текущей конфигурации пожалуйста.
> 
> PS Меньше пафоса больше дела.
> 
> -- 
> WBR et al.

В приложении сам diff.
Включать в дифф тарболлы с исходниками апстрима не вижу смысла.

[-- Attachment #1.2: llvm-10-11.diff --]
[-- Type: text/x-diff, Size: 17461 bytes --]

diff --git a/llvm10.spec b/llvm11.spec
index b8d4b6386..83c7f6535 100644
--- a/llvm10.spec
+++ b/llvm11.spec
@@ -1,7 +1,17 @@
-%global v_major 10.0
-%global llvm_name llvm%v_major
-%global clang_name clang%v_major
-%global lld_name lld%v_major
+%global v_major 11
+%global v_majmin %v_major.0
+%global llvm_name llvm%v_majmin
+%global clang_name clang%v_majmin
+%global lld_name lld%v_majmin
+
+%global llvm_prefix %_prefix/lib/llvm-%v_majmin
+%global llvm_bindir %llvm_prefix/bin
+%global llvm_libdir %llvm_prefix/%_lib
+%global llvm_includedir %llvm_prefix/include
+%global llvm_libexecdir %llvm_prefix/libexec
+%global llvm_datadir %llvm_prefix/share
+%global llvm_man1dir %llvm_datadir/man/man1
+%global llvm_docdir %llvm_datadir/doc
 
 # Decrease debuginfo verbosity to reduce memory consumption during final library linking
 %ifarch %ix86 %arm
@@ -19,11 +29,12 @@
 %endif
 
 Name: %llvm_name
-Version: 10.0.1
-Release: alt2
+Version: 11.0.0
+Release: alt1
 Summary: The Low Level Virtual Machine
 
 Group: Development/C
+# TODO: Apache-2-with-LLVM-exceptions
 License: NCSA
 Url: http://llvm.org
 Source0: https://github.com/llvm/llvm-project/releases/download/llvmorg-%version/llvm-%version.src.tar.xz
@@ -38,30 +49,32 @@ Patch4: llvm-alt-triple.patch
 Patch5: compiler-rt-9-alt-i586-arch.patch
 Patch6: RH-0001-CMake-Split-static-library-exports-into-their-own-ex.patch
 Patch7: clang-alt-aarch64-dynamic-linker-path.patch
-Patch8: 0001-Don-t-set-rpath-when-installing.patch
+#Patch8: 0001-Don-t-set-rpath-when-installing.patch # Is this needed?
 Patch9: lld-9-alt-mipsel-permit-textrels-by-default.patch
 Patch10: llvm-10-alt-python3.patch
-Patch11: CMake-CheckAtomic.cmake-catch-false-positives-in-RIS.patch
-Patch12: Support-Check-for-atomics64-when-deciding-if-latomic.patch
-Patch13: dsymutil-Explicitly-link-against-libatomic-when-nece.patch
-Patch14: llvm-10-alt-riscv64-config-guess.patch
-Patch15: llvm-upstream-D85007.patch
+#Patch11: CMake-CheckAtomic.cmake-catch-false-positives-in-RIS.patch # included in LLVM 11
+#Patch12: Support-Check-for-atomics64-when-deciding-if-latomic.patch # included in LLVM 11
+#Patch13: dsymutil-Explicitly-link-against-libatomic-when-nece.patch # included in LLVM 11
+#Patch14: llvm-10-alt-riscv64-config-guess.patch # we'll see
+#Patch15: llvm-upstream-D85007.patch # included in LLVM 11
 
-# ThinLTO requires /proc/cpuinfo to exists so the same does llvm
+# ThinLTO requires /proc/cpuinfo to exist; so the same does llvm
 BuildPreReq: /proc
 
 BuildRequires(pre): cmake >= 3.4.3
 BuildRequires: rpm-build >= 4.0.4-alt112 libncursesw-devel
-BuildRequires: chrpath libstdc++-devel libffi-devel perl-Pod-Parser perl-devel
+BuildRequires: libstdc++-devel libffi-devel perl-Pod-Parser perl-devel
 BuildRequires: python3-module-recommonmark zip zlib-devel binutils-devel ninja-build
 %if_with clang
-BuildRequires: %clang_name %llvm_name-devel %lld_name
+#BuildRequires: %clang_name %llvm_name-devel %lld_name
+# Use LLVM/Clang/LLD 10 to bootstrap LLVM/Clang/LLD 11.
+BuildRequires: clang10.0 llvm10.0-devel lld10.0
 %else
 BuildRequires: gcc-c++
 %endif
 
-Provides: llvm = %EVR
-Obsoletes: llvm < %version
+#Provides: llvm = %EVR
+#Obsoletes: llvm < %version
 
 %description
 LLVM is a compiler infrastructure designed for compile-time, link-time,
@@ -72,8 +85,8 @@ of programming tools as well as libraries with equivalent functionality.
 %package devel
 Group: Development/C
 Summary: Libraries and header files for LLVM
-Provides: llvm-devel = %EVR
-Obsoletes: llvm-devel < %version
+#Provides: llvm-devel = %EVR
+#Obsoletes: llvm-devel < %version
 Requires: %name = %EVR
 
 %description devel
@@ -83,8 +96,8 @@ native programs that use the LLVM infrastructure.
 %package devel-static
 Summary: Static libraries for LLVM
 Group: Development/C
-Provides: llvm-devel-static = %EVR
-Obsoletes: llvm-devel-static < %version
+#Provides: llvm-devel-static = %EVR
+#Obsoletes: llvm-devel-static < %version
 Requires: %name-devel = %EVR
 
 %description devel-static
@@ -102,8 +115,8 @@ Shared libraries for the LLVM compiler infrastructure.
 Summary: Documentation for LLVM
 Group: Documentation
 BuildArch: noarch
-Provides: llvm-doc = %EVR
-Obsoletes: llvm-doc < %version
+#Provides: llvm-doc = %EVR
+#Obsoletes: llvm-doc < %version
 
 %description doc
 Documentation for the LLVM compiler infrastructure.
@@ -112,8 +125,8 @@ Documentation for the LLVM compiler infrastructure.
 Summary: A C language family frontend for LLVM
 Group: Development/C
 Requires: gcc
-Provides: clang = %EVR
-Obsoletes: clang < %version
+#Provides: clang = %EVR
+#Obsoletes: clang < %version
 
 %description -n %clang_name
 clang: noun
@@ -135,8 +148,8 @@ Shared libraries for the clang compiler.
 %package -n %clang_name-devel
 Summary: Header files for clang
 Group: Development/C
-Provides: clang-devel = %EVR
-Obsoletes: clang-devel < %version
+#Provides: clang-devel = %EVR
+#Obsoletes: clang-devel < %version
 Requires: %clang_name = %EVR
 
 %description -n %clang_name-devel
@@ -145,8 +158,8 @@ This package contains header files for the Clang compiler.
 %package -n %clang_name-devel-static
 Summary: Static libraries for clang
 Group: Development/C
-Provides: clang-devel-static = %EVR
-Obsoletes: clang-devel-static < %version
+#Provides: clang-devel-static = %EVR
+#Obsoletes: clang-devel-static < %version
 Requires: %clang_name-devel = %EVR
 
 %description -n %clang_name-devel-static
@@ -156,8 +169,8 @@ This package contains static libraries for the Clang compiler.
 Summary: A source code analysis framework
 Group: Development/C
 BuildArch: noarch
-Provides: clang-analyzer = %EVR
-Obsoletes: clang-analyzer < %version
+#Provides: clang-analyzer = %EVR
+#Obsoletes: clang-analyzer < %version
 Requires: %clang_name = %EVR
 
 %description -n %clang_name-analyzer
@@ -170,8 +183,8 @@ intended to run in tandem with a build of a project or code base.
 Summary: Documentation for Clang
 Group: Documentation
 BuildArch: noarch
-Provides: clang-doc = %EVR
-Obsoletes: clang-doc < %version
+#Provides: clang-doc = %EVR
+#Obsoletes: clang-doc < %version
 
 %description -n %clang_name-doc
 Documentation for the Clang compiler front-end.
@@ -179,8 +192,8 @@ Documentation for the Clang compiler front-end.
 %package -n %lld_name
 Summary: LLD - The LLVM Linker
 Group: Development/C
-Provides: lld = %EVR
-Obsoletes: lld < %version
+#Provides: lld = %EVR
+#Obsoletes: lld < %version
 
 %description -n %lld_name
 LLD is a linker from the LLVM project. That is a drop-in replacement for system
@@ -190,8 +203,8 @@ useful for toolchain developers.
 %package -n %lld_name-devel
 Summary: Header files for LLD
 Group: Development/C
-Provides: lld-devel = %EVR
-Obsoletes: lld-devel < %version
+#Provides: lld-devel = %EVR
+#Obsoletes: lld-devel < %version
 Requires: %lld_name = %EVR
 
 %description -n %lld_name-devel
@@ -201,8 +214,8 @@ This package contains header files for the LLD linker.
 Summary: Documentation for LLD
 Group: Documentation
 BuildArch: noarch
-Provides: lld-doc = %EVR
-Obsoletes: lld-doc < %version
+#Provides: lld-doc = %EVR
+#Obsoletes: lld-doc < %version
 
 %description -n %lld_name-doc
 Documentation for the LLD linker.
@@ -221,19 +234,22 @@ mv compiler-rt-%version.src projects/compiler-rt
 %patch5 -p1 -b .alt-i586-arch
 %patch6 -p1
 %patch7 -p1 -b .alt-aarch64-dynamic-linker
-%patch8 -p1
+#patch8 -p1
 %patch9 -p1 -b .alt-mipsel-permit-textrels-by-default
 %patch10 -p1
-%patch11 -p1
-%patch12 -p1
-%patch13 -p1
-%patch14 -p1
-%patch15 -p2
+#patch11 -p1
+#patch12 -p1
+#patch13 -p1
+#patch14 -p1
+#patch15 -p2
 
 %build
+%define _cmake_skip_rpath -DCMAKE_SKIP_RPATH:BOOL=OFF
 %cmake -G Ninja \
 	-DLLVM_PARALLEL_LINK_JOBS=1 \
 	-DCMAKE_BUILD_TYPE=Release \
+	-DCMAKE_INSTALL_PREFIX=%llvm_prefix \
+	-DCMAKE_SKIP_INSTALL_RPATH:BOOL=OFF \
 	-DBUILD_SHARED_LIBS:BOOL=OFF \
 	-DLLVM_TARGETS_TO_BUILD="host;AMDGPU;BPF;NVPTX;" \
 	-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD='AVR' \
@@ -299,13 +315,13 @@ ninja -vvv -j %__nprocs -C BUILD
 
 %install
 pushd BUILD
-cmake -DCMAKE_INSTALL_PREFIX=%buildroot%prefix ../
+cmake -DCMAKE_INSTALL_PREFIX=%buildroot%llvm_prefix ../
 sed -i 's|man\ tools/lld/docs/docs-lld-html|man|' build.ninja
 sed -i '/^[[:space:]]*include.*tools\/lld\/docs\/cmake_install.cmake.*/d' tools/lld/cmake_install.cmake
 popd
 ninja -C BUILD install
 
-# And prepare Clang documentation
+# Prepare Clang documentation.
 rm -rf BUILD/clang-docs
 mkdir -p BUILD/clang-docs
 for f in LICENSE.TXT NOTES.txt README.txt; do
@@ -313,111 +329,162 @@ for f in LICENSE.TXT NOTES.txt README.txt; do
 done
 rm -rf tools/clang/docs/{doxygen*,Makefile*,*.graffle,tools}
 
-install -m 0755 BUILD/%_lib/LLVMHello.so %buildroot%_libdir/
-install -m 0755 BUILD/%_lib/BugpointPasses.so %buildroot%_libdir/
-mkdir -p %buildroot%_docdir/lld
-
-file %buildroot%_bindir/* | awk -F: '$2~/ELF/{print $1}' | xargs -r chrpath -d
-file %buildroot%_libdir/*.so | awk -F: '$2~/ELF/{print $1}' | xargs -r chrpath -d
+install -m 0755 BUILD/%_lib/LLVMHello.so %buildroot%llvm_libdir/
+install -m 0755 BUILD/%_lib/BugpointPasses.so %buildroot%llvm_libdir/
+mkdir -p %buildroot%llvm_docdir/lld
 
 %ifarch %ix86
-cd %buildroot%_libdir/clang/%version/lib/linux
+cd %buildroot%llvm_libdir/clang/%version/lib/linux
 ls *-i[3-9]86* | while read f; do ln -s $f $(echo $f | sed 's|i[3-9]86|i386|') ; done
 %endif
 
+# Symlink executables to %_bindir.
+mkdir -p %buildroot%_bindir
+for b in %buildroot%llvm_bindir/*; do
+	bb="$(basename "$b")"
+	echo "$bb" | grep -q -- '-%v_major$' && continue # if already appended
+	ln -srv "$b" "%buildroot%_bindir/$bb-%v_major"
+done
+# 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
+
 %check
 %if_enabled tests
-LD_LIBRARY_PATH=%buildroot%_libdir:$LD_LIBRARY_PATH
+LD_LIBRARY_PATH=%buildroot%llvm_libdir:$LD_LIBRARY_PATH
 export LD_LIBRARY_PATH
 ninja -C BUILD check-all || :
 %endif
 
 %files
 %doc CREDITS.TXT LICENSE.TXT README.txt
+%llvm_bindir/*
 %_bindir/*
+%llvm_man1dir/*
 %_man1dir/*
+%exclude %llvm_bindir/llvm-config*
 %exclude %_bindir/llvm-config*
+%exclude %llvm_bindir/*clang*
 %exclude %_bindir/*clang*
-%exclude %_bindir/c-index-test
+%exclude %llvm_bindir/c-index-test
+%exclude %_bindir/c-index-test-%v_major
+%exclude %llvm_bindir/scan-*
 %exclude %_bindir/scan-*
-%exclude %_man1dir/llvm-config.1.*
-%exclude %_man1dir/clang.1*
-%exclude %_man1dir/scan-build.1*
+%exclude %llvm_man1dir/llvm-config.1.*
+%exclude %_man1dir/llvm-config-%v_major.1.*
+%exclude %llvm_man1dir/clang.1*
+%exclude %_man1dir/clang-%v_major.1*
+%exclude %llvm_man1dir/scan-build.1*
+%exclude %_man1dir/scan-build-%v_major.1*
+%exclude %llvm_bindir/lld*
 %exclude %_bindir/lld*
-%exclude %_bindir/ld*.lld
-%exclude %_bindir/wasm-ld
+%exclude %llvm_bindir/ld*.lld
+%exclude %_bindir/ld*.lld-%v_major
+%exclude %llvm_bindir/wasm-ld
+%exclude %_bindir/wasm-ld-%v_major
 
 %files libs
-%_libdir/libLLVM-*.so
-%_libdir/libLTO.so.*
-%_libdir/libRemarks.so.*
+%llvm_libdir/libLLVM-*.so
+%llvm_libdir/libLTO.so.*
+%llvm_libdir/libRemarks.so.*
 
 %files devel
-%_bindir/llvm-config
-%_man1dir/llvm-config.1.*
-%_includedir/llvm
-%_includedir/llvm-c
-%_libdir/libLLVM.so
-%_libdir/libLTO.so
-%_libdir/LLVMgold.so
-%_libdir/libRemarks.so
-%_libdir/LLVMHello.so
-%_libdir/BugpointPasses.so
-%_datadir/cmake/Modules/llvm
-%_libdir/cmake/llvm/LLVMConfigExtensions.cmake
-%exclude %_datadir/cmake/Modules/llvm/LLVMStaticExports.cmake
+%llvm_bindir/llvm-config
+%_bindir/llvm-config-%v_major
+%llvm_man1dir/llvm-config.1.*
+%_man1dir/llvm-config-%v_major.1.*
+%llvm_includedir/llvm
+%llvm_includedir/llvm-c
+%llvm_libdir/libLLVM.so
+%llvm_libdir/libLTO.so
+%llvm_libdir/LLVMgold.so
+%llvm_libdir/libRemarks.so
+%llvm_libdir/LLVMHello.so
+%llvm_libdir/BugpointPasses.so
+%llvm_datadir/cmake/Modules/llvm
+%llvm_libdir/cmake/llvm/LLVMConfigExtensions.cmake
+%exclude %llvm_datadir/cmake/Modules/llvm/LLVMStaticExports.cmake
 
 %files devel-static
-%_libdir/*.a
-%exclude %_libdir/libclang*.a
-%_datadir/cmake/Modules/llvm/LLVMStaticExports.cmake
+%llvm_libdir/*.a
+%exclude %llvm_libdir/libclang*.a
+%llvm_datadir/cmake/Modules/llvm/LLVMStaticExports.cmake
 
 %files -n %clang_name
 %doc BUILD/clang-docs/*
+%llvm_bindir/*clang*
 %_bindir/*clang*
-%_bindir/c-index-test
-%_man1dir/clang.1*
+%llvm_bindir/c-index-test
+%_bindir/c-index-test-%v_major
+%llvm_man1dir/clang.1*
+%_man1dir/clang-%v_major.1*
 
 %files -n %clang_name-libs
-%_libdir/clang
-%_libdir/libclang*.so.*
+%llvm_libdir/clang
+%llvm_libdir/libclang*.so.*
 
 %files -n %clang_name-devel
-%_includedir/clang
-%_includedir/clang-c
-%_libdir/libclang*.so
-%_datadir/cmake/Modules/clang
+%llvm_includedir/clang
+%llvm_includedir/clang-c
+%llvm_libdir/libclang*.so
+%llvm_datadir/cmake/Modules/clang
 
 %files -n %clang_name-devel-static
-%_libdir/libclang*.a
+%llvm_libdir/libclang*.a
 
 %files -n %clang_name-analyzer
-%_prefix/libexec/*-analyzer
-%_bindir/scan-build
-%_bindir/scan-view
-%_datadir/scan-build
-%_datadir/scan-view
-%_man1dir/scan-build.1*
+%llvm_prefix/libexec/*-analyzer
+%llvm_bindir/scan-build
+%_bindir/scan-build-%v_major
+%llvm_bindir/scan-view
+%_bindir/scan-view-%v_major
+%llvm_datadir/scan-build
+%llvm_datadir/scan-view
+%llvm_man1dir/scan-build.1*
+%_man1dir/scan-build-%v_major.1*
 
 %files -n %lld_name
+%llvm_bindir/lld*
 %_bindir/lld*
-%_bindir/ld*.lld
-%_bindir/wasm-ld
+%llvm_bindir/ld*.lld
+%_bindir/ld*.lld-%v_major
+%llvm_bindir/wasm-ld
+%_bindir/wasm-ld-%v_major
 
 %files -n %lld_name-devel
-%dir %_includedir/lld
-%_includedir/lld/*
+%dir %llvm_includedir/lld
+%llvm_includedir/lld/*
 
 %files doc
-%doc %_docdir/llvm
+%doc %llvm_docdir/llvm
 
 %files -n %clang_name-doc
-%doc %_docdir/clang
+%doc %llvm_docdir/clang
 
 %files -n %lld_name-doc
-%doc %_docdir/lld
+%doc %llvm_docdir/lld
 
 %changelog
+* Tue Oct 13 2020 Arseny Maslennikov <arseny@altlinux.org> 11.0.0-alt1
+- 11.0.0
+- Installed to /usr/lib/llvm-11.0 to ensure peaceful co-existence with other
+  LLVM versions.
+
 * Wed Aug 12 2020 Aleksei Nikiforov <darktemplar@altlinux.org> 10.0.1-alt2
 - Applied upstream patch which should fix ppc64le-specific issue.
 
diff --git a/clang-9-alt-triple.patch b/clang-9-alt-triple.patch
index c19f8fa57..5ff28808d 100644
--- a/clang-9-alt-triple.patch
+++ b/clang-9-alt-triple.patch
@@ -87,11 +87,10 @@
  
    static const char *const RISCV32LibDirs[] = {"/lib32", "/lib"};
    static const char *const RISCV32Triples[] = {"riscv32-unknown-linux-gnu",
-@@ -2090,6 +2092,7 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
+@@ -2144,6 +2144,7 @@ void Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes(
    static const char *const RISCV64Triples[] = {"riscv64-unknown-linux-gnu",
                                                 "riscv64-linux-gnu",
                                                 "riscv64-unknown-elf",
 +                                               "riscv64-alt-linux",
+                                                "riscv64-redhat-linux",
                                                 "riscv64-suse-linux"};
- 
-   static const char *const SPARCv8LibDirs[] = {"/lib32", "/lib"};
diff --git a/lld-9-alt-mipsel-permit-textrels-by-default.patch b/lld-9-alt-mipsel-permit-textrels-by-default.patch
index 6c2e706ba..c94124f32 100644
--- a/lld-9-alt-mipsel-permit-textrels-by-default.patch
+++ b/lld-9-alt-mipsel-permit-textrels-by-default.patch
@@ -1,9 +1,9 @@
 --- llvm-9.0.1.src/tools/lld/ELF/Driver.cpp.alt-mipsel-permit-textrels-by-default	2020-02-10 12:20:18.165558849 +0000
 +++ llvm-9.0.1.src/tools/lld/ELF/Driver.cpp	2020-02-10 12:23:22.174099557 +0000
-@@ -936,7 +936,11 @@ static void readConfigs(opt::InputArgLis
-   config->zRetpolineplt = hasZOption(args, "retpolineplt");
-   config->zRodynamic = hasZOption(args, "rodynamic");
+@@ -1067,7 +1067,11 @@ static void readConfigs(opt::InputArgLis
+   config->zShstk = hasZOption(args, "shstk");
    config->zStackSize = args::getZOptionValue(args, OPT_z, "stack-size", 0);
+   config->zStartStopVisibility = getZStartStopVisibility(args);
 +#if defined __MIPSEL__ && !defined __mips64
 +  Config->ZText = getZFlag(Args, "text", "notext", false);
 +#else
@@ -11,4 +11,4 @@
 +#endif
    config->zWxneeded = hasZOption(args, "wxneeded");
  
-   // Parse LTO options.
+   for (opt::Arg *arg : args.filtered(OPT_z)) {

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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Konstantin Lepikhov]

Hi Arseny!

On 10/19/2020, at 06:40:37 PM you wrote:

> On Wed, Oct 14, 2020 at 11:41:00AM +0200, Konstantin Lepikhov wrote:
> > Hi Arseny!
> > 
> > Приведите полную ссылку на diff относительно текущей конфигурации пожалуйста.
> > 
> > PS Меньше пафоса больше дела.
> 
> В приложении сам diff.
> Включать в дифф тарболлы с исходниками апстрима не вижу смысла.

В сизифе я уже вижу llvm11, а ваши изменения почему-то относительно
llvm10. Наверное, стоит сделать rebase и сделать diff снова.

-- 
WBR et al.

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Dmitry V. Levin]

Hi,

On Tue, Oct 13, 2020 at 04:07:59PM +0300, Arseny Maslennikov wrote:
[...]
> Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> симлинками на исполнимые файлы и маны. llvm = %EVR и прочие провайды без
> номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
> /usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
> создавать лишних волнений в чужих пакетах раньше времени — кто собирался
> с llvm, clang, lld, по-прежнему получат свою десяточку.
> Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
> не надо — но кто-то может и не согласиться.

У меня наивный вопрос, нельзя ли просто собирать llvm в Сизиф по той же схеме,
что и gcc?


-- 
ldv

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 552 bytes --]

20.10.2020 12:33, Dmitry V. Levin пишет:
[...]
> У меня наивный вопрос, нельзя ли просто собирать llvm в Сизиф по той же схеме,
> что и gcc?

можно. я даже почти это сделал. да только как выяснилось это никому не
нужно, а тратить кучу времени на поддержку этой ненужности с каждым
новым релизом смысла не вижу

-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Alexey Gladkov]

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

On Tue, Oct 20, 2020 at 01:15:07PM +0300, Валерий Иноземцев wrote:
> 20.10.2020 12:33, Dmitry V. Levin пишет:
> [...]
> > У меня наивный вопрос, нельзя ли просто собирать llvm в Сизиф по той же схеме,
> > что и gcc?
> 
> можно. я даже почти это сделал. да только как выяснилось это никому не
> нужно, а тратить кучу времени на поддержку этой ненужности с каждым
> новым релизом смысла не вижу

Это очень нужно. Я бы этим пользовался. Не всё можно собрать последней
версией.

-- 
Rgrds, legion


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

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Dmitry V. Levin]

On Tue, Oct 20, 2020 at 01:15:07PM +0300, Валерий Иноземцев wrote:
> 20.10.2020 12:33, Dmitry V. Levin пишет:
> [...]
> > У меня наивный вопрос, нельзя ли просто собирать llvm в Сизиф по той же схеме,
> > что и gcc?
> 
> можно. я даже почти это сделал.

Почти не считается. :)

> да только как выяснилось это никому не нужно,

Что касается нужности, то в этом треде были приведены убедительные
аргументы в пользу востребованности разных версий llvm в репозитории.

> а тратить кучу времени на поддержку этой ненужности с каждым
> новым релизом смысла не вижу

Мой опыт с gcc подсказывает, что текущую схему упаковки gcc проще поддерживать.

Хуже всего в поддержке та схема упаковки llvm, которая сложилась сейчас:
дефолтная версия llvm вынужденно прибита гвоздями прямо в сборочной
системе и влияет сразу на все репозитории.  См. напр.
https://bugzilla.altlinux.org/39087 - при нынешней схеме упаковки llvm
это практически невозможно исправить.


-- 
ldv

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 1921 bytes --]

20.10.2020 13:34, Dmitry V. Levin пишет:
> On Tue, Oct 20, 2020 at 01:15:07PM +0300, Валерий Иноземцев wrote:
>> 20.10.2020 12:33, Dmitry V. Levin пишет:
>> [...]
>>> У меня наивный вопрос, нельзя ли просто собирать llvm в Сизиф по той же схеме,
>>> что и gcc?
>>
>> можно. я даже почти это сделал.
> 
> Почти не считается. :)
> 
>> да только как выяснилось это никому не нужно,
> 
> Что касается нужности, то в этом треде были приведены убедительные
> аргументы в пользу востребованности разных версий llvm в репозитории.

проснулись... спустя год

>> а тратить кучу времени на поддержку этой ненужности с каждым
>> новым релизом смысла не вижу
> 
> Мой опыт с gcc подсказывает, что текущую схему упаковки gcc проще поддерживать.

gcc хотя бы предполагает наличие нескольких версий, а апстриму llvm это
невдомек

> Хуже всего в поддержке та схема упаковки llvm, которая сложилась сейчас:
> дефолтная версия llvm вынужденно прибита гвоздями прямо в сборочной
> системе и влияет сразу на все репозитории.  См. напр.
> https://bugzilla.altlinux.org/39087 - при нынешней схеме упаковки llvm
> это практически невозможно исправить.

жесть какая то

-- 
Valery V. Inozemtsev


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Konstantin Lepikhov]

Hi Dmitry!

On 10/20/2020, at 12:33:25 PM you wrote:

> Hi,
> 
> On Tue, Oct 13, 2020 at 04:07:59PM +0300, Arseny Maslennikov wrote:
> [...]
> > Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> > симлинками на исполнимые файлы и маны. llvm = %EVR и прочие провайды без
> > номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
> > /usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
> > создавать лишних волнений в чужих пакетах раньше времени — кто собирался
> > с llvm, clang, lld, по-прежнему получат свою десяточку.
> > Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
> > не надо — но кто-то может и не согласиться.
> 
> У меня наивный вопрос, нельзя ли просто собирать llvm в Сизиф по той же схеме,
> что и gcc?
> 
llvm это как gcc/egcc/pgcc/binutils в одном флаконе, слишком сильная
турбулентность )

Мне кажется, зря тут все затачиваются на gcc, проще считать llvm некой qt
library и брать схему упаковки оттуда. Т.е. есть префикс, есть все тулзы
там в префиксе и либы сбоку. А портировать всю схему из gcc это очень
хлопотно и не окупится, т.к. основная потребность иметь несколько версий
llvm - это либо проекты которые не переползли на новый llvm и их нужно как
то тянуть, либо какой-то свежак-свежак для новых фич. Остальное это
кастомные libllvm внутри проекта выпиливать которые нет смысла.

PS я не претендую на авторитетное мнение, просто IMHO.

-- 
WBR et al.

Re: [devel] LLVM 11, поддержка нескольких llvm в репозитории

[Arseny Maslennikov]

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

On Tue, Oct 20, 2020 at 12:33:25PM +0300, Dmitry V. Levin wrote:
> Hi,
> 
> On Tue, Oct 13, 2020 at 04:07:59PM +0300, Arseny Maslennikov wrote:
> [...]
> > Я планирую собрать LLVM 11 в префикс /usr/lib/llvm-11.0, с проброшенными
> > симлинками на исполнимые файлы и маны. llvm = %EVR и прочие провайды без
> > номерка в имени пока что предоставляться не будут, как и /usr/bin/clang,
> > /usr/bin/ld.lld, etc.; пока будут /usr/bin/clang-11 и т. п., чтобы не
> > создавать лишних волнений в чужих пакетах раньше времени — кто собирался
> > с llvm, clang, lld, по-прежнему получат свою десяточку.
> > Саму десяточку я не трогаю и думаю, что упаковывать по-новому её уже и
> > не надо — но кто-то может и не согласиться.
> 
> У меня наивный вопрос, нельзя ли просто собирать llvm в Сизиф по той же схеме,
> что и gcc?
> 

Я к этому и стремлюсь.

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