Как менеджеры пакетов Linux будут обрабатывать модули C ++ 20?

Мы находимся в 2020 году, и C ++ 20 идет вместе с долгожданной функцией модулей C ++. Но после просмотра нескольких выступлений на CppCon я обнаружил, что модули C ++ находятся в странном месте, особенно для менеджеров пакетов Linux (pacman, apt, emerge и т. Д.)

Из того, что я узнал, модули C ++

Зависит от компилятора
- Вы не можете использовать модуль, созданный GCC в Clang
- Модули GCC 9.1 не будут работать на GCC 9.2
Вы можете иметь много разных версий одного и того же модуля
- Пока они не экспортируются в одну и ту же область
Вам нужно перестроить модуль, если обновятся его зависимости

Моя проблема в том, что во всех дистрибутивах с непрерывным выпуском компиляторы постоянно обновляются, и у пользователя может быть своя собственная компиляция. В настоящее время можно просто обновить компилятор или также обновить libstdc++. Но с модулями, кажется libstdc++, нужно обновлять при обновлении компилятора.

Как менеджер пакетов будет обрабатывать обновление, например, STL при обновлении компилятора? Я не думаю, что возможно создание каждой версии модуля STL для каждой версии компилятора. Также пользователю не нужно создавать собственный модуль STL.

— Мэри Чанг
источник

« Вы не можете использовать модуль, созданный GCC в Clang ». Вы не можете использовать скомпилированные результаты модуля, созданного GCC в Clang.

— Николь Болас

Я не могу уловить проблему. Можно распространять предварительно скомпилированные файлы модуля, но это не обязательно. Каждый пользователь может скомпилировать их один раз для каждого компилятора / версии, и все в порядке. Если пакет distro доставляет эти предварительно скомпилированные файлы, он сохраняет только одну компиляцию, которую мы сейчас делаем для каждой компиляции. Где выгода от доставки предварительно скомпилированных модулей? Загрузка / установка может занять больше времени, как компиляция один раз.

— Клаус

Какой вид анавера вы представляете, который не будет чистым предположением?

— нет. местоимения м.

@ Клаус Точно, нет никакой выгоды. Но большинство приложений разбиты на 2 части. Интерфейс и ядро lib. Таким образом, люди могут напрямую взаимодействовать с основной функциональностью. Возьмите, например, yosys. Это разделено на libyosys и yosys. Если libyosys решит использовать модули для более быстрой сборки, libyosys должен быть собран каждым пользователем. Эффективно превращая каждый менеджер пакетов в AUR или emerge.

— Мэри Чанг

@ n.'pronouns'm. Я надеялся, что разработчик менеджера пакетов увидит вопрос и объяснит, как они решают проблему.

— Мэри Чанг

На данный момент (январь / 10/2020) модульная система рассматривается скорее как внутренняя функция проекта, а не как замена заголовка / lib. Как предполагают ребята из сообщества Clang, хотя есть предложение создать независимую от компилятора форму AST, ни Clang, ни Gcc, ни Microsoft не планируют этого делать. Итак, вы догадываетесь о

Вы можете иметь много разных версий одного и того же модуля

прав и будет продолжать молчать некоторое время.

Что касается аспекта платформы управления пакетами, разрешение до сих пор неизвестно, но, поскольку модульная система является в большей степени внутренним компонентом проекта, в худшем случае все еще будет иметь место «header / lib».

PS Я думаю, что stackoverflow - не самое подходящее место для подобных вопросов. Если вы действительно хотите получить ответ, задайте этот список рассылки.

— ravenisadesk
источник