2

私は複雑な C++ プロジェクトを管理しています。そのビルド定義は で記述されCMake、ビルド自体は を呼び出すことによって取得されmakeます。ソースツリーは多くのモジュールで構成されており、並列化が容易です。

線形ビルドは常に成功しますが、並列ビルドはほとんどの場合成功します。このようなビルド中に依存関係の問題が発生した場合、通常は修正に取り掛かりますが、問題が発生したときに修正するのではなく、依存関係をプログラムでテストしたいと考えています。

理想的な解決策は、すべての依存関係をCMake調べて修正することですが、ソース ツリーに固有のある種の依存関係に対してカスタム マクロを頻繁に使用するため、これが実際に常に可能であるとは限りません (詳しくは説明できません)。 、 ごめん）。そこで、標準ツールをできるだけ再利用して、問題を別の方法で (そしておそらく効率的に) 解決することを考えていました。

  1. 私が最初に考えたのは、ジョブ スケジューリングにある種の「ランダム性」を注入することでしたMake。これにより、ビルド マシンは、障害が発生するまでツリーを再構築することで、さまざまなコンパイル パスを無期限に試行できるようになりました。ただし、別の質問(こちら)では、この機能は では使用できないと指摘されましたMake。

  2. だから私は別の解決策を試しました.ジョブスケジューラにノイズをもたらすg++ために、数秒間スリープするラッパースクリプトを作成しました。もちろん、このソリューションの欠点は、コンパイル時間が長くなることです。 ただし、この部分的な解決策には根本的な欠陥があります。問題が見つかった場合、依存関係が存在しないことが証明されますが、エラーが発生しなければ、すべての依存関係が正しいことを証明することはできません。$RANDOMMake

どう思いますか？どうすれば目標を達成できますか? 標準ツールを再利用し、幅広いユーザーに適用できるソリューションを希望します。

ありがとう。

4

2 に答える 2

3

makeこの問題を本当に効率的に解決したいのなら、もっとうまく使う必要があると思います。Electric Make（ElectricAcceleratorの一部）はGNU makeと互換性のあるバリアントであり、ビルド中にファイルシステムアクセスを監視し、アウトオブオーダー実行によって引き起こされた問題makeを自動的に検出して修正します。さらに、ElectricMakeは、ビルド内の各ジョブがアクセスしたファイルと、ジョブ間の依存関係（明示的および暗黙的）を示す注釈付きのビルドログを生成できます。これを使用して、makefileで欠落している依存関係を修正できます。 。

ElectricAcceleratorのフリーミアムバージョンであるElectricAcceleratorHuddleをダウンロードして試すことができます。

免責事項：私はElectricAcceleratorのアーキテクトおよびテクニカルリードです。

于 2012-07-27T17:57:16.723 に答える
1

依存関係自体を分析してみてください。Cmake は dot/graphviz でかなり簡単に依存グラフを生成できます: http://www.cmake.org/Wiki/CMake:For_CMake_Hackers

いくつかのグラフ理論が分析に役立つかもしれません: http://en.wikipedia.org/wiki/Graph_theory

于 2013-11-28T04:10:23.110 に答える