LLVM/Packaging: различия между версиями

Материал из ALT Linux Wiki
(Новая страница: «Мы упаковываем несколько мажорных версий LLVM, пользуясь опытом дистрибутива Debian и нашей же упаковки разных мажорных {{pkg|gcc}}. * Пакеты с мажорной версией ''в имени'' содержат упакованные компоненты LLVM. * Пакеты без мажорной версии ''в имени'' вытягивают паке...»)
 
Нет описания правки
 
(не показана 1 промежуточная версия этого же участника)
Строка 6: Строка 6:
Подобно переменной окружения <tt>GCC_VERSION</tt>, мы вводим переменную окружения <tt>ALTWRAP_LLVM_VERSION</tt>, на которую реагирует программа <tt>llvm-alt-tool-wrapper</tt>.
Подобно переменной окружения <tt>GCC_VERSION</tt>, мы вводим переменную окружения <tt>ALTWRAP_LLVM_VERSION</tt>, на которую реагирует программа <tt>llvm-alt-tool-wrapper</tt>.
Она либо исполняет утилиту с именем симлинка, по которому её вызвали, либо, если таковой нет, выдаёт диагностическое сообщение и совет, что администратору нужно сделать.
Она либо исполняет утилиту с именем симлинка, по которому её вызвали, либо, если таковой нет, выдаёт диагностическое сообщение и совет, что администратору нужно сделать.
У этой envvar такое страшное название, потому что она предназначена в первую очередь '''для сборочных скриптов в RPM-пакетах''' — у пользователей CMake и Meson (да и остальных) есть более удобные инструменты по выбору правильной утилиты. В RPM-спеках не стоит завязываться; лучше применять макросы из {{pkg|rpm-macros-llvm-common}}.
У этой envvar такое страшное название, потому что она предназначена в первую очередь '''для сборочных скриптов в RPM-пакетах''' — у пользователей CMake и Meson (да и остальных) есть более удобные инструменты по выбору правильной утилиты. В RPM-спеках '''не стоит завязываться на эту переменную'''; лучше применять макросы из {{pkg|rpm-macros-llvm-common}}.


== Изменения упаковки, отражающиеся на спеках других пакетов ==
== Изменения упаковки, отражающиеся на спеках других пакетов ==
=== LLVM 13 ===
=== LLVM 13 ===
* В этой мажорной ветке апстрим окончательно сломал раздельную упаковку <tt>.a</tt> и <tt>.so</tt>, поэтому мы больше не уносим .a в <tt>-devel-static</tt>. Дело облегчается тем, что динамическая библиотека во всех подпроектах одна, общая (<tt>libLLVM-X.so</tt>, <tt>libclang-cpp.so.X</tt>, <tt>liblldb.so.X</tt>), а статические <tt>.a</tt> разделены (<tt>libclangBasic.a</tt>, <tt>libclangLex.a</tt>, <tt>libclangAST.a</tt>, ...; <tt>libLLVMX86CodeGen.a</tt>, <tt>libLLVMX86Disassembler.a</tt>, <tt>libclangBasic.a</tt>).
* В этой мажорной ветке апстрим окончательно сломал раздельную упаковку <tt>.a</tt> и <tt>.so</tt>, поэтому мы больше не уносим .a в <tt>-devel-static</tt>. Дело облегчается тем, что динамическая библиотека во всех подпроектах одна, общая (<tt>libLLVM-X.so</tt>, <tt>libclang-cpp.so.X</tt>, <tt>liblldb.so.X</tt>), а статические <tt>.a</tt> разделены (<tt>libclangBasic.a</tt>, <tt>libclangLex.a</tt>, <tt>libclangAST.a</tt>, ...; <tt>libLLVMX86CodeGen.a</tt>, <tt>libLLVMX86Disassembler.a</tt>, <tt>libLLVMRISCVDisassembler.a</tt>...).
** При переводе спека на другую версию LLVM (или, если вы не прибиваете её гвоздями — при смене дефолта в репозитории) обратите внимание на <tt>BuildRequires: (llvm|clang)-devel-static</tt>. Начиная с LLVM 13, такого пакета нет, и достаточно просто <tt>-devel</tt>.
** При переводе спека на другую версию LLVM (или, если вы не прибиваете её гвоздями — при смене дефолта в репозитории) обратите внимание на <tt>BuildRequires: (llvm|clang)-devel-static</tt>. Начиная с LLVM 13, такого пакета нет, и достаточно просто <tt>-devel</tt>.
** Также мы произвели это слияние devel-пакетов для LLVM 12, но оставили там для совместимости provide на <tt>-devel-static</tt>.
** Также мы произвели это слияние devel-пакетов для LLVM 12, но оставили там для совместимости provide на <tt>-devel-static</tt>.

Текущая версия от 14:25, 12 апреля 2022

Мы упаковываем несколько мажорных версий LLVM, пользуясь опытом дистрибутива Debian и нашей же упаковки разных мажорных gcc.

  • Пакеты с мажорной версией в имени содержат упакованные компоненты LLVM.
  • Пакеты без мажорной версии в имени вытягивают пакет из предыдущего пункта c некоторой версией по умолчанию, а также устанавливают симлинки без номера. Например, пакет clang в некотором репозитории может устанавливать симлинк %_bindir/clang на %_prefix/lib/llvm-14.0/bin/clang и вытягивать пакет с clang-14. (На самом деле мы ставим симлинки на свою маленькую программу, которая уже вызывает настоящую утилиту; подробнее ниже)

Подобно переменной окружения GCC_VERSION, мы вводим переменную окружения ALTWRAP_LLVM_VERSION, на которую реагирует программа llvm-alt-tool-wrapper. Она либо исполняет утилиту с именем симлинка, по которому её вызвали, либо, если таковой нет, выдаёт диагностическое сообщение и совет, что администратору нужно сделать. У этой envvar такое страшное название, потому что она предназначена в первую очередь для сборочных скриптов в RPM-пакетах — у пользователей CMake и Meson (да и остальных) есть более удобные инструменты по выбору правильной утилиты. В RPM-спеках не стоит завязываться на эту переменную; лучше применять макросы из rpm-macros-llvm-common.

Изменения упаковки, отражающиеся на спеках других пакетов

LLVM 13

  • В этой мажорной ветке апстрим окончательно сломал раздельную упаковку .a и .so, поэтому мы больше не уносим .a в -devel-static. Дело облегчается тем, что динамическая библиотека во всех подпроектах одна, общая (libLLVM-X.so, libclang-cpp.so.X, liblldb.so.X), а статические .a разделены (libclangBasic.a, libclangLex.a, libclangAST.a, ...; libLLVMX86CodeGen.a, libLLVMX86Disassembler.a, libLLVMRISCVDisassembler.a...).
    • При переводе спека на другую версию LLVM (или, если вы не прибиваете её гвоздями — при смене дефолта в репозитории) обратите внимание на BuildRequires: (llvm|clang)-devel-static. Начиная с LLVM 13, такого пакета нет, и достаточно просто -devel.
    • Также мы произвели это слияние devel-пакетов для LLVM 12, но оставили там для совместимости provide на -devel-static.