From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS autolearn=no autolearn_force=no version=3.4.1 From: Aleksey Cheusov Envelope-From: cheusov@tut.by To: ALT Linux Team development discussions In-Reply-To: <20200520190931.GE154014@glebfm.cloud.tilaa.com> References: <20200520074634.GA30268@gyle.altlinux.org> <20200520093414.GA154014@glebfm.cloud.tilaa.com> <173841589971618@mail.yandex.ru> <20200520121450.GB154014@glebfm.cloud.tilaa.com> <114911589989822@mail.yandex.ru> <20200520190931.GE154014@glebfm.cloud.tilaa.com> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 20 May 2020 22:41:46 +0300 Message-Id: <139831590002860@mail.yandex.ru> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Subject: Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207)) X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 19:41:50 -0000 Archived-At: List-Archive: List-Post: 20.05.2020, 22:11, "Gleb Fotengauer-Malinovskiy" : > 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 на стол. А ляжет ему конфиг для компилятора, которого в системе нет, и компилятор, для которого нет конфига. Некрасиво.