4

slnVisual Studio 、vcproj、vcxprojファイル、またはXCode xcodeprojOS X のプロジェクトなど、プラットフォーム固有のプロジェクト ファイルを生成できるビルド システムがいくつかあります。

そのうちの 1 つが CMake ですが、これのサポートは非​​常に限定的でバグが多く、新しいバージョン (VS 2010 など) で更新し続けることが非常に難しいことがわかりました。

また、少なくとも CMake は Visual Studio のプロパティ ページのサポートを欠いているため、すべてのプロジェクトのコード分析の有効化/無効化など、プロジェクト全体の構成の管理と変更が難しくなっています。

上記の問題の回避策は、プラットフォームごとに手動でプロジェクト ファイルを作成することです。私の場合は 2 つしかありませんが、それ以上の数があってもそれほど大きくはなりません。

プラットフォーム固有のビルド コマンドを一般的なビルド自動化スクリプトに呼び出すのは非常に簡単です。たとえばwaf、独自のビルド部分を使用せずに、いくつかのプロジェクトでこれを自動化するために (Python) を使用しました。

プロジェクト ジェネレーターの修復/保守を試みるか、プロジェクト ファイルを分離して保持するか、どちらを選択するかを確認したいと思います。

4

3 に答える 3

3

最善の方法ではないかもしれませんが、これは私たちにとって非常にうまく機能し、維持するのはそれほど難しくないことがわかりました。

私たちの主なプラットフォームは Windows で、ほぼすべての開発は VS IDE で行われます。他のプラットフォーム (現時点では一部の Linux フレーバーのみ) では、CMake のみを使用します。基本的に、「プロジェクト ジェネレーターを修復/維持しようとする」方法を選択しましたが、Visual Studio プロジェクト ファイルを出発点として使用しました。

  • プロジェクト内のすべてのファイルのコンテナーとして Visual Studio プロジェクト ファイルを使用します。
  • すべてのビルド オプションはプロパティ シートで設定され、各プロジェクトには標準セットがあり、最終的には特定のライブラリを取り込むためのいくつかの追加シートがあります。
  • 1 回のバッチでプロパティ シートを追加/削除できる簡単なスクリプトがいくつかあります。
  • すべてのプロパティ シートには、対応する cmake があります。両方とも同じディレクトリに保持され、一方を更新すると、常に他方も更新されます。これはスクリプトでは行われません。これが「複雑な」部分であることは認めます。私たちはマクロに重点を置いていますが、あるプラットフォームでは利用できるオプションがあり、他のプラットフォームでは利用できないオプションが常にあります。
  • vcproj ファイルを cmake ファイルに変換するスクリプトがあります。基本的には、対応する cmake プロパティ シートを含み、vcproj が持つすべてのソース ファイルを含む cmake ファイルを作成します。
  • 最後になりましたが、私たちが使用するすべてのプラットフォームで実行されるビルド サーバーを作成しました。msbuild または cmake を使用してビルドします。これは、このシステムを機能させ続けるための鍵です。変更を加えるたびに、少なくとも 2 台のマシンでビルドとテストがトリガーされるため、問題がないかどうかがすぐにわかります。

私たちは最近 VS2010 を使い始めましたが、移行には約 1 日しかかかりませんでした。最初に VS にすべてのプロジェクトとプロパティ シートを変換させ、次にスクリプトを調整して新しい xml ファイル形式を処理しました。

編集

申し訳ありませんが、スクリプト、会社のポリシーを投稿することはできません。ご理解いただければ幸いです。ただし、少しの疑似コードは問題ありません。VS2008 プロジェクト ファイルのプロパティ シートの追加/削除は次のようになります。

foreach proj in projectfiles //list of vcproj files
  foreach config in configuration //configurations eg 'Debug|Win32, Debug|x64'
    f = OpenFile( proj );
      //find start of Configuration element, then get what's after InheritedPropertySheets=
    propsheets = GetPropSheetsForConfig( f, config );
    propsheets = DoAction( action, args, propsheets ); //action is add/remove/.. with argument args
    SetPropSheetsForConfig( f, propsheets );

CMakeLists ファイルの場合、スクリプトが「include(..)」行で機能することを除いて、これはほとんど同じです。

vcproj から CMakeLists への変換:

f = OpenFile( proj );
projname = GetProjectName( f );
sources = GetSourceFiles( f ); //all File/RelativePath elements under Filter 'Source Files'
sources = CheckFilter( sources ); //apply rules to include/exclude platform specific files
propsheets[] = GetPropSheetsForConfig( f, configs[] );

fout = CreateCMakeFromProj( proj ); //CMakeLists.txt in corresponding directory
WriteCMakeHeader( fout, projname );
WriteCMakeSources( sources );
WriteCMakeIncludes( configs[], propsheets[] ); //write includes, conditional on CMAKE_BUILD_TYPE

ビルド サーバーは今では非常に高度な素材ですが、最初は単なる TCP リスナーでした。

  • 接続を待つ
  • オプションの引数を取得 (プロパティ シート/アクション)
  • リポジトリの更新
  • 最終的に、指定された引数でプロパティ シートのバッチ スクリプトを実行します。
  • コマンド ラインのフル リビルド + テストを開始し、出力をファイルにキャプチャします
  • 「エラー」を含む行の解析ファイル、メール結果
于 2009-12-24T09:11:02.373 に答える
0

プラットフォームプロジェクトにはboost.buildを使用します。これは、C++ライブラリプロジェクトに適しています。スクリプトを1つだけ維持する必要があり、Boost.Testとうまく統合できるため、これが気に入っています。

それは非常に急な学習曲線を持っており、ドキュメントはかなり貧弱です。しかし、私たちが取り組んでいる2つのプラットフォームであるWindowsとLinuxではうまく機能します。

于 2010-01-11T16:15:46.633 に答える
0

私のプロジェクトはすべてクロスプラットフォームであり、私の好みは回避策です。Scons を使用すると、クロス プラットフォーム プロジェクトを維持することは、ほとんどまたはまったく作業になりません。適切に定義された 1 つの環境は、ほとんどのプロジェクトで機能し、プロジェクト/サブプロジェクトごとにテンプレートを使用します。また、構築プロセスを完全に制御できるという利点もあり、ドメイン固有言語の使用、コード生成、ソース管理の管理を簡単に行うことができます。

Scons の学習は、Python を知っていれば非常に簡単です。Python を知らなくても、1 つではなく 2 つの優れたテクノロジを発見することになります ;)

于 2010-01-11T09:47:30.677 に答える