4

私は scons を初めて使用し、多くの VS プロジェクト ファイル (.vcxproj) を内部的に参照する既存のビジュアル スタジオ ソリューション (.sln) を移植しようとしています。さまざまなライブラリやさまざまな実行可能ファイルなど、複数の出力があります。

概念的な観点から、私は正しい道を進んでいるかどうか確信が持てず、より良い方法についてアドバイスをいただければ幸いです。

これが私のセットアップです：

コードデポのルートに最上位の SConstruct ファイルがあります。さらに、古い VS プロジェクト ファイルごとに 1 つの SConscript ファイルがあります。SConstruct ファイルは、これらの SConscript ファイルごとに SConscript 関数を 1 回呼び出します。この関数では、ソース ディレクトリと出力先をパラメーターとして指定します。

さらに、SConstruct ファイルは、scons 環境インスタンスの配列を作成し、各 SConstruct ファイルに渡します。たとえば、ライブラリのコンパイル用、実行可能ファイルのコンパイル用、デバッグ構成用、リリース用などがあります。各 SConscript ファイルは、達成しようとしていることに基づいて、必要なものを選択します。

私が疑問に思っていたことがいくつかあります: 1) 構成のバリエーションごとに 1 つずつ、複数の異なる環境を作成するよりも良いアプローチはありますか? それは予想される使用パターンですか？2) ビジュアル スタジオでは、特定のプロジェクトを右クリックして [ビルド] を選択し、そのプロジェクトとそれが依存するプロジェクトのみをビルドし、sln の残りの依存関係グラフを無視することができます。scons を使用すると、特定のライブラリのビルドをトリガーするたびに依存関係グラフ全体を再計算するというのは本当ですか?理論的には、依存関係グラフ全体のごく一部を計算するだけで済みます。

アドバイスをありがとう。

マーク

4

1 に答える 1

0

SConstruct に複数の従属 SConscript ファイルを呼び出すアプローチは、実際にプロジェクトを編成するための優れた方法であり、階層 SCons ビルドと呼ばれます。

ご質問に関しては、次の点を考慮してください。

  1. いくつかの異なる環境:ビルダーまたはターゲット (ライブラリ、実行可能ファイルなど) ごとに異なるコンパイラまたはコンパイラ フラグがない限り、使用しているアプローチは少しやり過ぎだと言えます。ほとんどの場合、1 つの環境だけで同じことを達成できます。サブディレクトリ/ビルダーごとに追加のフラグが必要な場合は、「メイン」環境をサブディレクトリに渡し、それぞれの SConscript で env を複製し、ここで説明したように必要なものを追加/追加することを検討できます。このようにして、ソリューション全体がよりモジュール化され、繰り返しを回避し、すべてを 1 か所で共通に保つことができます。

  2. 特定のプロジェクト/ターゲットのビルド: 次のように、コマンド ラインでターゲットを選択することにより、SCons で同じことを行うことができます$ scons yourTarget。env.Alias()関数を使用して、ターゲット名をより管理しやすくすることができます。SCons は確かにビルド前にすべてを分析しますが、プロジェクトのサイズによっては、問題になることはなく、それでも非常に高速です。ビルドのパフォーマンスが問題になる場合は、パフォーマンスを改善するためのヒントをいくつか紹介します。

知っておくと便利なことをいくつか紹介します。

  • SConsのドキュメントは、他のオープンソース ツールにとって悪い WRT ではありません。そのドキュメント ページの下部には、多くの追加情報を含むいくつかの付録があります。SConsのman ページも非常に充実しています。
  • ここで述べたように「#」を使用していない場合、SCons でパスが混乱する可能性があります。
  • MSVS プロジェクトを扱う必要がある場合は、ここで説明されているように MSVSProject() および MSVSSolution() ビルダーを使用できます。
于 2012-05-27T10:47:09.970 に答える