Почему в экосистемах Unix и Linux так мало инноваций со сценариями конфигурации autoconf? [закрыто]

Любой ответ будет, по крайней мере, немного спекуляцией ИМО, поскольку то, что представляет собой «инновация», отличается от человека к человеку (и хорошо ли это! )Поскольку autoconfпо большей части не зависит от языка -и архитектуры -,есть много инерции, которая сдерживает желание меняться :вы должны учитывать, что некоторым скриптам конфигурации, вероятно, уже несколько десятков лет, и люди не хотят переписывать то, что работает.

Некоторые из ограничений, с которыми сталкивается autoconf, связаны с архитектурой. :Например, как можно использовать многопоточность на шаге, который проверяет многопоточность? Будет ли версия 2.5 libfooработать с программой, которая говорит, что ей нужна версия 1.8? Другие проблемы, на которые вы ссылаетесь, часто связаны с недостаточной спецификацией зависимостей. :У меня было много сценариев настройки, которые просто забывали перечислить все свои прямые зависимости. Наконец, autoconfимеет довольно ограниченное число сопровождающих, что затрудняет внесение значительных изменений.

В некотором смысле именно в пакетных менеджерах происходит инновация. Они могут иметь дело с такими понятиями, как разные пакеты, требующие разных версий одной и той же библиотеки, определять обходные пути для зависимостей, которые больше не доступны, и (для исходных -компилирующих дистрибутивов, таких как Gentoo ), предоставлять исправления для очистки скриптов конфигурации и исходный код, чтобы они работали правильно.

Autoconf, конечно, кэширует результаты, и если вы используете его правильно, вы редко запускаете configure.

Мой проект schilytools (> 4000 исходных файлов, прибл. 770000 строк кода )в настоящее время требуют ок. 800 тестов автоконф. Выполнение всех тестов занимает 28 секунд на ноутбуке Intel с тактовой частотой 2,7 ГГц, 2 -3 часа на коробке для пиццы HP -9000 1995 года, 4 -6 часов на Sun3/60 1996 года и прибл. в день на Vax 11/780.

Мне по-прежнему не о чем беспокоиться, так как скрипт configure изменяется только прибл. 5 раз в год, а повторный запуск configureзанимает всего 4 секунды на ноутбуке Intel, так как все остальные тесты кэшируются. У меня, конечно, есть правило make, которое заставляет configureзапускаться снова, только если результаты конфигурации устарели.

Нижние люди придерживаются другого мнения.Они воспринимают проект как одноразовый пакет и запускают его configure30 раз в год, что занимает 15 минут в год.

Мне, с другой стороны, приходится ждать всего 25 секунд в год....

Таким образом, проблема заключается в том, как нижестоящие люди используют программное обеспечение.