[devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))
Aleksey Cheusov
vle на gmx.net
Ср Май 20 22:41:46 MSK 2020
20.05.2020, 22:11, "Gleb Fotengauer-Malinovskiy" <glebfm на altlinux.org>:
> On Wed, May 20, 2020 at 07:10:13PM +0300, Aleksey Cheusov wrote:
>> С учетом вот этого замечания
>>
>> | На %e2k есть такой же метапакет gcc, но с другой базовой версией
>> | (макрос %__gcc_version_base при этом работает, так что проблем с
>> | этим нет). А вот пакетов gcc%__gcc_version_base на самом деле нет,
>> | поэтому такая проверка не сработает. С другой стороны, с ветки на
>> | ветку мы прыгаем редко, поэтому мне не сложно будет ещё один пакет
>> | пересобрать.
>>
>> я так и не понял, что нужно сделать, чтобы и e2k поддерживался без ifndef.
>
> Всё равно, единого решения не будет скорее всего, но Андрей же обещает не
> забывать пересобирать и без зависимости, насколько я понял.
Ну, в этом случае смотрящий за сизифом меня действительно возненавидит.
Хотелось бы, конечно, чтобы оно само пересобиралось автоматом
и никого не дергать.
В идеале хотелось бы механизм, который бы тригернул
пересборку mk-c при изменении любого из штатных компиляторов gcc/clang.
Если такого механизма реально нет, тогда придется или пересобирать
его в сизифе вручную (как это сделано сейчас) или как-то костылить.
Если предложенный выше вариант "тригернет" пересборку, значит это
правильный вариант. Что делать с Эльбрусом мы можем offlist
обсудить, чтобы не спамить тут.
>> Конфигурирационные переменные USE_{CC,CXX}_COMPILERS содержат список
>> компиляторов, особенности которых нужно собрать и сохранить в mk/ в процессе установки.
>> Скрипт mkc_compiler_settings нужен для того, чтобы оставалась возможность
>> собрать что-то любым другим/неродным компилятором, если очень хочется. При его запуске
>> особенности компилятора записываются пользователю в HOME.
>
> Вот тут я архитектурно с самого начала не понимаю -- если можно не падать
> и посмотреть, что за компилятор сейчас есть, то зачем вообще падать?
Чтобы не захламлять HOME юзера без его явного указания, например.
> Если бы вы не были автором этого инструиента, то я бы просто предложил
> положить вызов mkc_compiler_settings в макрос и забыть об этой странности,
> а так я могу ещё выразить своё недоумение прямо тут -- зачем падать, если
> можно не падать потратив лишнюю секунду?
Дернуть mkc_compiler_settings при сборке каждого пакета можно, и, конечно, это будет
работать. Но вопрос не только в том, чтобы все собралось, но и в том, что ляжет
пользователю mk-c на стол. А ляжет ему конфиг для компилятора, которого в системе нет,
и компилятор, для которого нет конфига. Некрасиво.
Подробная информация о списке рассылки Devel