./configureを高速化することは可能ですか？

ので、多くのCPUコア（12と言う）とワークステーション上のソフトウェア・パッケージをコンパイルするには、コンフィギュレーション・ステージは、多くの場合、実際のコンパイル段階よりもはるかに長い時間がかかる./configureテストを一つずつんが、make -j実行するgccだけでなく、他のコマンドに並列に。

残りの11個のコアをほとんどの時間アイドル状態にして、遅いもの./configureが完了するのを待つのは、リソースの大きな浪費だと感じています。なぜテストを連続して行う必要があるのですか？各テストは互いに依存していますか？私は間違っているかもしれませんが、それらの大半は独立しているようです。

さらに重要なことは、スピードアップする方法はあります./configureか？

編集：状況を説明するために、GNU Coreutilsの例を示します

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

結果：

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

coreutils-8.9、./configure6回より長くかかりますmake。が./configure使用少ないCPU時間（「ユーザー」＆「SYS」の回で見て）それが並列化されていないので、それははるかに長い（「リアル」）かかります。テストを数回繰り返しましたが（関連ファイルはおそらくメモリキャッシュに残っています）、時間は10％以内です。

ほとんどの人が実際には1つのCPUコアしか持っていなかった約10年前のAutoconfメーリングリストでのこの問題に関する議論を思い出します。しかし、何も行われておらず、何も行われないと思います。で並列処理のすべての依存関係を設定し、configure移植可能で堅牢な方法で設定することは非常に困難です。

特定のシナリオによっては、とにかくconfigureの実行を高速化するいくつかの方法があります。例えば：

• より高速なシェルを使用してください。たとえばdash、bashasの代わりにを使用することを検討してください/bin/sh。（注：Debianでは、使用すると多くのスクリプトが破損するため、使用しないdashようにパッチが適用されます。）configureconfigure
• ビルドをリモートで（たとえばsshを介して）実行すると、コンソールの出力がかなり遅くなることがあります。を呼び出すことを検討してくださいconfigure -q。
• 同じプロジェクトを繰り返しビルドする場合は、キャッシュファイルの使用を検討してください。を呼び出しconfigure -Cます。詳細については、Autoconfのドキュメントを参照してください。
• さまざまなプロジェクトを構築する場合は、サイトファイル（config.site）の使用を検討してください。繰り返しますが、ドキュメントを参照してください。
• 複数のプロジェクトを並行してビルドします。

ramdriveを使用してソースツリーを常駐させるのは賢明ですが、考え直してください-configureは何をしますか？sourcetreeだけでなく、ライブラリ、コンパイラなどの可用性のシステムも頻繁にチェックします。この場合、アクセスの問題はディスクアクセスにある場合があります。たとえば、SSDベースのルートファイルシステム。

オンデマンドCPUガバナーを使用している場合は、パフォーマンスガバナーを使用してみてください。これは、i7およびa8-3850で40〜50％役立ちます。q9300ではそれほど違いはありません。

クアッドコアCPUでは、

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

（-rオプションを使用すると、各コアに対してcpufreq-setを実行する必要がなくなりますが、私のコンピューターでは機能しません。）

ただし、キャッシュオプションはさらに役立ちます。

./configureスクリプトには多くの種類があります。開発者がスクリプトを作成するのに役立つ一般的なツール（autconfがその1つ）./configureがありますが、すべての開発者がこれらのツールを使用する必要があるというルールはありません。構築されます。

./configure並行して実行できる一般的なスクリプトについては知りません。一般的なツールで作成されたスクリプトのほとんどは、少なくとも一部またはすべての結果をキャッシュするため、（make clean最初に実行せずに）再度実行すると、2回目にははるかに高速に実行されます。

それができなかったと言っているわけではありません...しかしautoconf、例えば、ほとんどのパッケージでは、実際のコンパイルとリンクに比べて設定フェーズが非常に速いため、作業している人々にはほとんど動機がないと思いますフェーズ。

この場合、ハードドライブがボトルネックです。ビルドを高速化するには、高速ドライブを搭載したシステムでビルドします（読み取り：アクセス時間の短縮）。SSDディスクには大騒ぎがありますが、それらがコンパイル時間にプラスの影響を与えないという批判がありました。つまり、SSDでの構築は、まともなSATAドライブでの構築ほど高速ではありませんでした。この記事は数年前のものなので、どこで読んだか思い出せません。

とにかく...展開してそこからビルドします。

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

シングルコアのパフォーマンスが（かなり）低い12コアのCPUを使用しているため、今日のあなたの質問はさらに関連性があります。継続的インテグレーション（CI）の自動ビルドは、コミットごとに大量のCPU時間/エネルギーを本当に無駄にします。ブランチ間のホッピングと同じです。

https://gitlab.com/gnuwget/wget2/wikis/D​​eveloper-hints:-Increasing-speed-of-GNU-toolchainで事を高速化するためのヒントを確認/読んでください。

「テストを順番に実行する必要があるのはなぜですか？...」実際には、並行して実行できることがいくつかありますが、他のものは順番に実行する必要があります。ビルド環境に依存するものがいくつかあります-configureスクリプト自体はシステムに依存しません。bashismも含まれていないため、純粋なPOSIXシェルで動作します。

ポータブルソフトウェアを作成する場合、autotoolsのような他のビルドシステムはありません。ただし、（幅広い）移植性を気にしない場合は、自動ツールを避けてください。高速で十分なビルドツールが多数あります。