Исходное сообщение
"Представлен GTK+ 3.92.1, экспериментальный выпуск GTK+ 4" Отправлено Mihail Zenkov, 25-Окт-17 21:44
>> Сделал программу, которая собирает config.cache после сборки. Потом запускаю вторую программу, которая анализирует все имеющиеся config.cache и создает config.site, в который попадают только те переменные, которые имеют одно и тоже значение во всех config.cache. > И это работает? Собираем всю систему и попутно собираем все config.cache. Генерируем config.site. Повторная сборка системы будет гораздо быстрее. Но да, все это можно легко сломать. > Другое дело, что может если собрать переменные, которые стопудов никогда не меняются > (скажем, относящиеся к проверкам libc и cc) и один раз их > сложить в config.site... Таких переменных не так уж и много. Выигрыш будет не большой. Тут нужна методика четко позволяющая отделить переменные и константы для конкретно вашей системы. Есть у меня мысль попробовать исключить все переменные, которые используются менее трех раз. Но в итоге и встает вопрос, а стоит ли оно того? >  Таким образом, чтобы с этого получить хоть какой-нибудь бонус по скорости, надо это всё автоматизировать, а для этого надо лезть в портажи и перелопачивать eclass'ы. У меня своя система сборки. На все правки, включая написание программ для сборки и обработки config.cache ушло 3-4 часа. Но как я сказал, выигрыш не велик, а вероятность получить проблемы после очередных изменений в системе далеко не нулевая. С другой стороны, если появилась проблема - отключаем config.site и собираем как обычно. Вроде ничего сложного. Вообще нужно поработать с этим какое-то время, чтобы набрать некоторую статистику по отказам.