> У меня своя система сборки. На все правки, включая написание программ для
> сборки и обработки config.cache ушло 3-4 часа.

Поддержание своей системы сборки будет требовать гораздо больше времени. Все эти задачи связанные с обсчётом депендансов, выкачиванием сорцов нужных версий из нужных мест по нужным протоколам, обходом всех специальных случаев... В gentoo это решается написанием ебилда на каждый пакет. Но, вот, допустим, я пользуюсь оверлеем rust, чтобы иметь в системе расты разных версий, причём хоть самых-самых nightly. Иногда это требует правки ебилдов. Но мне приходилось отказываться от внесения каких-то изменений, потому что это были изменения, которые не примут в "апстрим", а самостоятельно поддерживать эти изменения я не готов совершенно. Внести и отправить пулл-реквест -- легко: поигрался с ebuild, выполняя работу emerge поэтапно, создал патч, оттестил его, отправил и забыл. А вот следить за актуальностью моего форка оверлея -- не, спасибо, вот заняться мне больше нечем. Если что, я могу и потерпеть пару месяцев, а там проблема тем или иным способом разрешится.

> С другой стороны, если появилась проблема - отключаем config.site и собираем как
> обычно. Вроде ничего сложного.

Я в генту последнее время избегаю использовать keyword'ы типа ~amd64, потому что практика показывает, что эти флаги накапливаются в /etc/portage, и лет через десять это кончается тем, что либо emerge не может обсчитать зависимости, либо сборка внезапно обламывается в какой-то момент, и если месяц не обновлял мир, то потом такое обновление займёт пару часов (моего времени, не процессорного) в то, чтобы найти причины отказов и устранить их. И хорошо, если все эти причины выявятся на этапе обсчёта депендансов, а не начнут выскакивать в рандомные моменты сборки, в течение нескольких часов работы emerge. В общем, приемлимый для меня компромисс между надёжностью и конфигурабельностью со временем смещается в сторону надёжности.

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

Если мы попытаемся этот config.site впилить, например, в emerge и дополнить этим костылём с рестартом сборки, то встанет вопрос: как мы можем выяснить программно, что сборка обломалась из-за косяков с config.site? Или после каждого облома мы на всякий случай будем удалять config.site и делать рестарт -- а вдруг прокатит?

> Но как я сказал, выигрыш не велик, а вероятность получить проблемы после очередных изменений в системе далеко не нулевая.

Да, на самом деле эта вероятность получить проблемы и есть основная претензия к autotools.

autotools -- это такое хакерское решение: минимумом усилий максимум результата. Но *nix в своём развитии ушёл за границы возможного для autotools, требования изменились. Изменилась и среда: сегодня нет необходимости тщательно проверять компиляторы C, потому что времена, когда каждый компилятор C имел свои собственные нюансы реализации, ушли в прошлое (почему C не считался кроссплатформенным языком в 80-е, да и в 90-е в общем-то? Как раз потому, что написать код, который скомпилируется двумя разными компиляторами и будет при этом работать как надо -- это был высший пилотаж программирования на C). Потому что есть стандарты и не только на компиляторы, но и на libc и на многое другое. Потому что есть pkg-config, который легко можно использовать непосредственно из makefile'а, проверяя наличие библиотек и их версии. Потому, что есть github, где очень легко отправлять pull-реквесты, получать их, создавать issues, обсуждать их, и находить решения: сегодня если софтина не собирается на какой-то особо хитрой конфигурации, то этим проблемам несложно найти решение и без autotools. Тем более, что autotools не решает этих проблем: configure в лучшем случае, поможет диагностировать эти проблемы. Потому, наконец, что сегодня из сорцов собирают только те, кому это интересно и кто готов разбираться в чём проблема, а не любой пользователь *nix, и просто потому, что других способов поставить софт не существует. А тем, кому интересно собирать софт из сорцов, совсем не обязательно иметь configure для того, чтобы делать сообщения об ошибках более информативными.

Если комментаторы опеннета в большинстве своём и выступают против замены autotools на что-то ещё, то это их "старпёрский bias" -- опеннетовское когнитивное искажение, вызванное тем, что каждому опеннетовцу хочется выглядеть старпёром, а лучший способ выглядеть старпёром -- всегда выступать в пользу музейного софта и всегда против всего нового.