Некоторые пакеты выиграют от сборки с PGO (profile-guided optimization). Такая сборка есть в некоторых дистрибутивах (clearlinux) и уже есть в некоторых пакетах в ALT. Общая задача, чтоб на неё ссылаться. [1] https://en.wikipedia.org/wiki/Profile-guided_optimization [2] https://lwn.net/Articles/830300/ Profile-guided optimization for the kernel
Есть идея делать %prep + %build да раза, первый раз в optflags добавляется: -fprofile-generate -fprofile-dir=/tmp/pgo -fprofile-update=atomic второй раз: -fprofile-use -fprofile-dir=/tmp/pgo -fprofile-correction + между ними делается find /tmp/pgo -name '*conftest.gcda' -delete. Для профилирования используется или %check, или можно сделать макро %profile_use_exit, которое помещается в конец %build перед генерацией профиля - в первом проходе он не делает ничего, а во втором exit 0. Идея Глеба - дополнить spec секцией (скажем) %profile_generate, где находится скрипт генерирующий профиль и само наличие этой секции запускает двойной build с PGO. (В ней можно было бы, например, задавать и тип PGO с -fprofile-partial-training или без. Ну или управлять этим через макрос.)
(Ответ для Vitaly Chikunov на комментарий #1) > Есть идея делать %prep + %build да раза, первый раз в optflags добавляется: > > -fprofile-generate -fprofile-dir=/tmp/pgo -fprofile-update=atomic > > второй раз: > > -fprofile-use -fprofile-dir=/tmp/pgo -fprofile-correction > > + между ними делается find /tmp/pgo -name '*conftest.gcda' -delete. (Погуглил: это какие-то особые файлы, которые мешают второй стадии.) > Для профилирования используется или %check, или можно сделать макро Я ещё подумал о получении feedback для второй сборки извне (из girar) и запуск второй сборки тоже извне. При первом прогоне некоторые rpm собираются для профилирования, т.е. негодные для публикации. Потом всякие install check-и сохраняют информацию из обговоренного места (типа /feedback/for-SRPMNAME/*). Делается второй прогон (итерация задания, где должны ещё собираться пакеты, которым это требуется), во время которого подкладывается собранная информация. Она может быть из нескольких источников (install check разных бинарных пакетов и вообщеоткуда угодно при желании), так что её надо разложить как-то так: /feedback/for-SRPMNAME/from-GENERATOR1/* /feedback/for-SRPMNAME/from-GENERATOR2/* ... Там можно сделать перед использованием на втором прогоне gcov-tool --merge разных источников информации. Возникает мысль, что для воспроизводимости сборки нужно эту использованную информацию (профиль) сохранить рядом или внутри src.rpm. Только внутри сложно, потому что тогда меняется id src.rpm, да и для разных архитектур она разная. (Ну при желании использовать для этого формат src.rpm, понятный rpmbuild, можно хранить общий для всех архитектур оригинальный src.rpm, и для каждой архитектуры ещё свой с дополнительной информацией, можно без тех Source, которые есть в оригинальном, т.е. nosrc.rpm.) * * * У меня раньше были мысли о механизме feedback из girar для второй окончательной итерации сборки в связи с желанием исключить из Provides неимпортируемые python3-модули, так чтобы лишний раз не напрягать мейнтейнеров (автоматическая вторая итерация), но и не раздувать сборочную среду (BuildRequires), усложняя граф сборочных зависимостей циклами, поэтому не делать это полностью внутри одного запуска rpmbuild.
(Ответ для Ivan Zakharyaschev на комментарий #2) > /feedback/for-SRPMNAME/from-GENERATOR1/* > /feedback/for-SRPMNAME/from-GENERATOR2/* > ... > > Там можно сделать перед использованием на втором прогоне gcov-tool --merge > разных источников информации. gcov-tool merge сливает пары (этого достаточно, чтобы слить и большее множество).
