[devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Gleb Fotengauer-Malinovskiy]

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

Hi,

On Wed, May 20, 2020 at 07:46:34AM +0000, ALT beekeeper wrote:
> 	11 NEW error logs
> 
> libmaa-1.4.7-alt1
> 	+ export MANDIR=/usr/share/man
> 	+ MANDIR=/usr/share/man
> 	+ mkcmake
> 	all ===> doc
> 	all ===> maa
> 	checking C compiler type... gcc 9.3.1
> 	bmake[1]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for
> 	gcc-9.3.1 is not available, run "mkc_compiler_settings" utility'
> 	*** Error code 1
> 	Stop.
> 	bmake: stopped in /usr/src/RPM/BUILD/libmaa-1.4.7
> 
> paexec-1.1.3-alt1
> 	+ MANDIR=/usr/share/man
> 	+ mkcmake
> 	checking custom test custom_awk_fflush... 1
> 	checking for program runawk... /usr/bin/runawk
> 	all ===> paexec
> 	checking C compiler type... gcc 9.3.1
> 	bmake[1]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for
> 	gcc-9.3.1 is not available, run "mkc_compiler_settings" utility'
> 	*** Error code 1
> 	Stop.
> 	bmake: stopped in /usr/src/RPM/BUILD/paexec-1.1.3
> 
> runawk-1.6.1-alt1
> 	+ SYSCONFDIR=/etc
> 	+ export MANDIR=/usr/share/man
> 	+ MANDIR=/usr/share/man
> 	+ mkcmake all
> 	all ===> runawk
> 	checking C compiler type... gcc 9.3.1
> 	bmake[1]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for
> 	gcc-9.3.1 is not available, run "mkc_compiler_settings" utility'
> 	*** Error code 1
> 	Stop.
> 	bmake: stopped in /usr/src/RPM/BUILD/runawk-1.6.1

Значит ли это, что при сборке этих пакетов нужно всегда запускать
mkc_compiler_settings?  Или это значит, что после обновления компилятора
нужно пересобирать mk-configure?

Ещё в этих пакетах не используются наши дистрибутивные %optflags при
сборке, в итоге на первый взгляд даже -O там нет, напришиваются какие-то
макросы для использования mk-configure в спеках.

-- 
glebfm

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

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Aleksey Cheusov]

20.05.2020, 12:35, "Gleb Fotengauer-Malinovskiy" <glebfm@altlinux.org>:
> Hi,
>
> On Wed, May 20, 2020 at 07:46:34AM +0000, ALT beekeeper wrote:
>>          11 NEW error logs
>>          checking C compiler type... gcc 9.3.1
>>          bmake[1]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for
>>          gcc-9.3.1 is not available, run "mkc_compiler_settings" utility'
>>          *** Error code 1
>>          Stop.
>>          bmake: stopped in /usr/src/RPM/BUILD/runawk-1.6.1
>
> Значит ли это, что при сборке этих пакетов нужно всегда запускать
> mkc_compiler_settings?

Нет, конечно.

> Или это значит, что после обновления компилятора
> нужно пересобирать mk-configure?

Да. И я не знаю, как этого добиться.

> Ещё в этих пакетах не используются наши дистрибутивные %optflags при
> сборке, в итоге на первый взгляд даже -O там нет, напришиваются какие-то
> макросы для использования mk-configure в спеках.

Макросы сделаю, да, чуть позже, когда разберусь с этим получше.
Что касается флагов, можно выставить переменную COPTS.

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Gleb Fotengauer-Malinovskiy]

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

On Wed, May 20, 2020 at 01:49:23PM +0300, Aleksey Cheusov wrote:
> 20.05.2020, 12:35, "Gleb Fotengauer-Malinovskiy" <glebfm@altlinux.org>:
> > Hi,
> >
> > On Wed, May 20, 2020 at 07:46:34AM +0000, ALT beekeeper wrote:
> >>          11 NEW error logs
> >>          checking C compiler type... gcc 9.3.1
> >>          bmake[1]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 112: 'Settings for
> >>          gcc-9.3.1 is not available, run "mkc_compiler_settings" utility'
> >>          *** Error code 1
> >>          Stop.
> >>          bmake: stopped in /usr/src/RPM/BUILD/runawk-1.6.1
> >
> > Значит ли это, что при сборке этих пакетов нужно всегда запускать
> > mkc_compiler_settings?
> 
> Нет, конечно.
> 
> > Или это значит, что после обновления компилятора
> > нужно пересобирать mk-configure?
> 
> Да. И я не знаю, как этого добиться.

(Сейчас я просто его вручную пересобрал.)

Ну, скажем, чтобы не забывать это делать можно написать в mk-configure

Requires: gcc = %__gcc_version_base
Requires: gcc%__gcc_version_base = %__gcc_version

Первое чтобы привязаться к текущей (на момент сборки) ветке gcc, которая
используется по умолчанию.  Второе чтобы в этой ветке привязаться к
конкретной версии.  Ещё и всё это скорее всего под %ifnarch %e2k, потому
что у них там отельный мир «Полезных ископаемых нет. Воды нет.
Растительности нет...».

Всё это хороший способ попробовать заставить майнтейнера компилятора
немножко вас ненавидеть, а вот профит мне не очень понятен.  Если при
пересборке или после запуска mkc_compiler_settings инструмент может
переварить, что компилятор поменялся, может его стоит научить это делать и
без явного приминения этих средств?

> > Ещё в этих пакетах не используются наши дистрибутивные %optflags при
> > сборке, в итоге на первый взгляд даже -O там нет, напришиваются какие-то
> > макросы для использования mk-configure в спеках.
> 
> Макросы сделаю, да, чуть позже, когда разберусь с этим получше.
> Что касается флагов, можно выставить переменную COPTS.

Ну вот проще было бы чтобы это тоже делал макрос, 

Ещё вопрос -- чем так всем пользователям mkc не угодил MAKEFLAGS?

-- 
glebfm

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

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Gleb Fotengauer-Malinovskiy]

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

On Wed, May 20, 2020 at 03:14:50PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> Ещё вопрос -- чем так всем пользователям mkc не угодил MAKEFLAGS?

А, ну тут я сообразил уже -- видимо bmake не умеет -O .

-- 
glebfm

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

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Andrey Savchenko]

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

On Wed, 20 May 2020 15:14:50 +0300 Gleb Fotengauer-Malinovskiy
wrote:
> On Wed, May 20, 2020 at 01:49:23PM +0300, Aleksey Cheusov wrote:
> > 20.05.2020, 12:35, "Gleb Fotengauer-Malinovskiy" <glebfm@altlinux.org>:
[...]
> > > Или это значит, что после обновления компилятора
> > > нужно пересобирать mk-configure?
> > 
> > Да. И я не знаю, как этого добиться.
> 
> (Сейчас я просто его вручную пересобрал.)
> 
> Ну, скажем, чтобы не забывать это делать можно написать в mk-configure
> 
> Requires: gcc = %__gcc_version_base
> Requires: gcc%__gcc_version_base = %__gcc_version
> 
> Первое чтобы привязаться к текущей (на момент сборки) ветке gcc, которая
> используется по умолчанию.  Второе чтобы в этой ветке привязаться к
> конкретной версии.  Ещё и всё это скорее всего под %ifnarch %e2k, потому
> что у них там отельный мир «Полезных ископаемых нет. Воды нет.
> Растительности нет...».

На %e2k есть такой же метапакет gcc, но с другой базовой версией
(макрос %__gcc_version_base при этом работает, так что проблем с
этим нет). А вот пакетов gcc%__gcc_version_base на самом деле нет,
поэтому такая проверка не сработает. С другой стороны, с ветки на
ветку мы прыгаем редко, поэтому мне не сложно будет ещё один пакет
пересобрать.

> Всё это хороший способ попробовать заставить майнтейнера компилятора
> немножко вас ненавидеть, а вот профит мне не очень понятен.  Если при
> пересборке или после запуска mkc_compiler_settings инструмент может
> переварить, что компилятор поменялся, может его стоит научить это делать и
> без явного приминения этих средств?

Согласен, если есть возможность автоматически определять параметры
среды, лучше её использовать.

Best regards,
Andrew Savchenko

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

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Aleksey Cheusov]

20.05.2020, 15:16, "Gleb Fotengauer-Malinovskiy" <glebfm@altlinux.org>:
> On Wed, May 20, 2020 at 01:49:23PM +0300, Aleksey Cheusov wrote:
>>  > Или это значит, что после обновления компилятора
>>  > нужно пересобирать mk-configure?
>>
>>  Да. И я не знаю, как этого добиться.
>
> (Сейчас я просто его вручную пересобрал.)
>
> Ну, скажем, чтобы не забывать это делать можно написать в mk-configure
>
> Requires: gcc = %__gcc_version_base
> Requires: gcc%__gcc_version_base = %__gcc_version

С учетом вот этого замечания

| На %e2k есть такой же метапакет gcc, но с другой базовой версией
| (макрос %__gcc_version_base при этом работает, так что проблем с
| этим нет). А вот пакетов gcc%__gcc_version_base на самом деле нет,
| поэтому такая проверка не сработает. С другой стороны, с ветки на
| ветку мы прыгаем редко, поэтому мне не сложно будет ещё один пакет
| пересобрать.

я так и не понял, что нужно сделать, чтобы и e2k поддерживался без ifndef.

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

Параметры среды как раз и определяются динамически -- во время сборки mk-c.
Если в системе компилятор, сажем, gcc-8.3.0,
зачем пересчитывать одно и тоже по сто раз?
Конфигурирационные переменные USE_{CC,CXX}_COMPILERS содержат список
компиляторов, особенности которых нужно собрать и сохранить в mk/ в процессе установки.
Скрипт mkc_compiler_settings нужен для того, чтобы оставалась возможность
собрать что-то любым другим/неродным компилятором, если очень хочется. При его запуске
особенности компилятора записываются пользователю в HOME.

> Первое чтобы привязаться к текущей (на момент сборки) ветке gcc, которая
> используется по умолчанию. Второе чтобы в этой ветке привязаться к
> конкретной версии. Ещё и всё это скорее всего под %ifnarch %e2k, потому
> что у них там отельный мир «Полезных ископаемых нет. Воды нет.
> Растительности нет...».

Наличие странных компиляторов меня абсолютно не пугает.
Самое худшее, что может произойти -- lcc распознается
как unknown версии 0.0.0. Поддержать его upsteam
несложно, надо что-нибудь прописать сюда
https://github.com/cheusov/mk-configure/blob/master/scripts/mkc_check_compiler.in
и, возможно, сюда
https://github.com/cheusov/mk-configure/blob/master/mk/mkc_imp.compiler_settings.mk

> Если при пересборке или после запуска mkc_compiler_settings инструмент может
> переварить, что компилятор поменялся, может его стоит научить это делать и
> без явного приминения этих средств?

См. выше.

>>  > Ещё в этих пакетах не используются наши дистрибутивные %optflags при
>>  > сборке, в итоге на первый взгляд даже -O там нет, напришиваются какие-то
>>  > макросы для использования mk-configure в спеках.
>>
>>  Макросы сделаю, да, чуть позже, когда разберусь с этим получше.
>>  Что касается флагов, можно выставить переменную COPTS.
>
> Ну вот проще было бы чтобы это тоже делал макрос,

Это понятно.

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Gleb Fotengauer-Malinovskiy]

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

On Wed, May 20, 2020 at 07:10:13PM +0300, Aleksey Cheusov wrote:
> 20.05.2020, 15:16, "Gleb Fotengauer-Malinovskiy" <glebfm@altlinux.org>:
> > On Wed, May 20, 2020 at 01:49:23PM +0300, Aleksey Cheusov wrote:
> >>  > Или это значит, что после обновления компилятора
> >>  > нужно пересобирать mk-configure?
> >>
> >>  Да. И я не знаю, как этого добиться.
> >
> > (Сейчас я просто его вручную пересобрал.)
> >
> > Ну, скажем, чтобы не забывать это делать можно написать в mk-configure
> >
> > Requires: gcc = %__gcc_version_base
> > Requires: gcc%__gcc_version_base = %__gcc_version
> 
> С учетом вот этого замечания
> 
> | На %e2k есть такой же метапакет gcc, но с другой базовой версией
> | (макрос %__gcc_version_base при этом работает, так что проблем с
> | этим нет). А вот пакетов gcc%__gcc_version_base на самом деле нет,
> | поэтому такая проверка не сработает. С другой стороны, с ветки на
> | ветку мы прыгаем редко, поэтому мне не сложно будет ещё один пакет
> | пересобрать.
> 
> я так и не понял, что нужно сделать, чтобы и e2k поддерживался без ifndef.

Всё равно, единого решения не будет скорее всего, но Андрей же обещает не
забывать пересобирать и без зависимости, насколько я понял.

> > Согласен, если есть возможность автоматически определять параметры
> > среды, лучше её использовать.
> 
> Параметры среды как раз и определяются динамически -- во время сборки mk-c.
> Если в системе компилятор, сажем, gcc-8.3.0,
> зачем пересчитывать одно и тоже по сто раз?

Предлагаете экономить на спичках?

> Конфигурирационные переменные USE_{CC,CXX}_COMPILERS содержат список
> компиляторов, особенности которых нужно собрать и сохранить в mk/ в процессе установки.
> Скрипт mkc_compiler_settings нужен для того, чтобы оставалась возможность
> собрать что-то любым другим/неродным компилятором, если очень хочется. При его запуске
> особенности компилятора записываются пользователю в HOME.

Вот тут я архитектурно с самого начала не понимаю -- если можно не падать
и посмотреть, что за компилятор сейчас есть, то зачем вообще падать?

Если бы вы не были автором этого инструиента, то я бы просто предложил
положить вызов mkc_compiler_settings в макрос и забыть об этой странности,
а так я могу ещё выразить своё недоумение прямо тут -- зачем падать, если
можно не падать потратив лишнюю секунду?

-- 
glebfm

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

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Aleksey Cheusov]

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 на стол. А ляжет ему конфиг для компилятора, которого в системе нет,
и компилятор, для которого нет конфига. Некрасиво.

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Andrey Savchenko]

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

On Wed, 20 May 2020 22:41:46 +0300 Aleksey Cheusov wrote:
> 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.

Я предлагаю сделать так:

Requires: gcc = %__gcc_version_base
%ifnarch %e2k
Requires: gcc%__gcc_version_base = %__gcc_version
%endif

Первая зависимость у нас на %e2k поддерживается.
Вторая попросту не нужна, т.к. в рамках одной ветки lcc эмулируемая
версия gcc не меняется, даже patch version.
Сами ветки меняются редко, поэтому номер базовой версии
гарантированно изменится при переходе на новую ветку.

Best regards,
Andrew Savchenko

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

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Andrey Savchenko]

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

On Wed, 20 May 2020 23:35:08 +0300 Andrey Savchenko wrote:
> On Wed, 20 May 2020 22:41:46 +0300 Aleksey Cheusov wrote:
> > 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.
> 
> Я предлагаю сделать так:
> 
> Requires: gcc = %__gcc_version_base
> %ifnarch %e2k
> Requires: gcc%__gcc_version_base = %__gcc_version
> %endif

Я добавил в gcc-defaults-e2k нужные Provides на полную версию gcc,
так что теперь можно убрать %ifnarch %e2k. Раньше у нас никаким
пакетам это не требовалось, поэтому и не задавали.

Best regards,
Andrew Savchenko

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

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Michael Shigorin]

On Wed, May 20, 2020 at 10:41:46PM +0300, Aleksey Cheusov wrote:
> Дернуть mkc_compiler_settings при сборке каждого пакета можно,
> и, конечно, это будет работать. Но вопрос не только в том,
> чтобы все собралось, но и в том, что ляжет пользователю mk-c на
> стол. А ляжет ему конфиг для компилятора, которого в системе
> нет, и компилятор, для которого нет конфига. Некрасиво.

У нас в пользовательских системах обычно компилятора нет,
а в разработческих никто не обязывает (ну, не обязывал)
держать тот же, которым была собрана установленная когда-то
система.  То есть у тебя происходит принудительная фиксация
ситуации buildtime через installtime в runtime, причём мне
тоже непонятно -- чего ради.

В конце концов, можно сваливаться на какой cc/c++ -O2
(в случае альта -- подставив %optflags вместо -O2), не?

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

Re: [devel] mk-configure vs gcc

[Alexey V. Vissarionov]

On 2020-05-21 15:40:09 +0300, Michael Shigorin wrote:

 >> Дернуть mkc_compiler_settings при сборке каждого пакета можно,
 >> и, конечно, это будет работать. Но вопрос не только в том,
 >> чтобы все собралось, но и в том, что ляжет пользователю mk-c на
 >> стол. А ляжет ему конфиг для компилятора, которого в системе
 >> нет, и компилятор, для которого нет конфига. Некрасиво.
 > У нас в пользовательских системах обычно компилятора нет, а в
 > разработческих никто не обязывает (ну, не обязывал) держать тот
 > же, которым была собрана установленная когда-то система.
 > В конце концов, можно сваливаться на какой cc/c++ -O2 (в случае
 > альта -- подставив %optflags вместо -O2), не?

Тогда уж сразу %__cc %optflags


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] mk-configure vs gcc (was: [cyber] I: Sisyphus-20200520 x86_64 beehive_status: +11 -15 (207))

[Aleksey Cheusov]

20.05.2020, 12:35, "Gleb Fotengauer-Malinovskiy" <glebfm@altlinux.org>:
> напришиваются какие-то макросы для использования mk-configure в спеках.

Сделал макросы. task #252091.
В него входят: 
mk-configure-0.34.2-alt4 с макросами, и
libmaa-1.4.7-alt2 и 1.6.1-alt2, где макросы используются.

Нужен review