UnixとLinuxのエコシステムのautoconf設定スクリプトに革新がほとんどないのはなぜですか？ [閉鎖]

./configure を呼び出すと、特に依存関係が欠落し、後続の呼び出しが発生した場合、多くの時間が無駄になります。

再利用のために構成スクリプトの結果をキャッシュすることを参照しているこのトピックに関する多くのスレッドを読みました。その他構成スクリプトは、結果が古く、同期されず、エラーが発生しやすく、結果を共有する一般的な実装を作成することは「難しい」[1]。

私は設定スクリプトがすでにキャッシュをサポートしていることを知っていますが、これはデフォルトでは無効になっています。[2]。

ディストリビューションが既に相互依存関係を理解するパッケージマネージャを提供し、すべての共通（または最も一般的な）ソース依存関係が何であるかを既に知っている場合、ディストリビューションがキャッシュ構成のための標準の一種を提供しないのはなぜですか。特定の条件が与えられると、パッケージマネージャは、これらのテストの多くを全く実行する必要がないと評価できると仮定することができる。または、少なくとも構成中に問題が発生しない限り、そうではありません。

他の多くの競合ビルドシステムがありますが、私はConfigがまだ最も人気があることに気づきました。これらのスクリプトはシェルベースのシングルスレッドであり、エラーが発生しやすく、診断情報を暗号化または提供しないことが多く、非常に遅いことがよくあります。構成の一部ではない依存関係がないため、構成スクリプトが失敗したりコンパイルが失敗したりすることは珍しくありません。

この問題を解決したディストリビューションはありますか？たとえば、Gentooは多くのネイティブコンパイルを実行します。彼らはこれを最適化しますか？

私はビルドシステムのアドバイスを探しているのではなく、現代のプロジェクトが依然としてautoconfと構成に大きく依存している理由についての歴史的または文化的な視点を探しています。これはおそらく意見の領域に属する可能性が高いですが、建築慣行、会社政策、白髪の慣習に基づいて公正な事実を持つことができる非常に興味深いテーマだと思います。

メーリングリストについても同様の主張が可能です。メーリングリストは、Web上の最新のコラボレーション形式に比べて時代遅れですが、単純で単純さを考慮してほとんど変更がないため、常にやってきたのと同じ機能を実行します。たぶんautoconfも同様の運命を持っていますか？ （免責事項：私は実際にメーリングリストが大好きです。どんな苦情でもメールクライアント側の過酷なサポートが原因です。）