11

プロジェクト/ソリューションのセットアップを使用するのではなく、Visual Studio C++ ビルド (VS 2005 の下) のメイクファイルを使用した経験がある人はいますか? 私たちにとって、プロジェクト/ソリューションの動作は直感的ではなく、特定のコンパイル時フラグを使用してビルドを微調整しようとすると、構成が爆発的に増加します。

Unix では、デフォルトのオプションがユーザー設定 (またはその他の構成設定) によって上書きされるメイクファイルをセットアップするのは非常に簡単です。しかし、Visual Studio でこのようなことを行うのは難しいようです。

例として、3 つの異なるプラットフォーム用にビルドする必要があるプロジェクトがあります。各プラットフォームには、いくつかの構成 (たとえば、デバッグ、リリース、およびその他のいくつか) がある場合があります。新しく形成されたプロジェクトでの私の目標の 1 つは、すべてのプラットフォーム ビルドを一緒に構築できるソリューションを用意することです。これにより、コードをテストするためだけに 3 つの異なるソリューションを開く必要がないため、コードの変更のビルドとテストが容易になります。ただし、Visual Studio には 3 * (基本構成の数) の構成が必要です。つまり、PC デバッグ、X360 デバッグ、PS3 デバッグなどです。

ここでは、makefile ソリューションの方がはるかに優れているようです。いくつかの基本的なバッチファイルまたはスクリプトでラップすると、構成の展開を最小限に抑え、実行する必要があるさまざまなビルドすべてに対して少数のファイル セットのみを維持することが容易になります。

ただし、Visual Studio でメイクファイルを使用した経験はありません。共有できる経験や問題があるかどうかを知りたいです。

ありがとう。

(これらが C++ ビルドであることを言及するために編集された投稿)

4

5 に答える 5

5

私は、主にプロジェクト設定の場所を統一することに関連して、大規模なプロジェクトのメイクファイルにいくつかの利点があることを発見しました。ソース ファイルのリスト、インクルード パス、プリプロセッサ定義などを管理するのは、それらがすべて makefile またはその他のビルド構成ファイルにある場合は、いくぶん簡単です。複数の構成では、インクルード パスを追加すると、Visual Studio の面倒なプロジェクト プロパティを使用してすべての構成を手動で更新する必要があることを意味します。これは、プロジェクトのサイズが大きくなるにつれてかなり面倒になる可能性があります。

ピクセル/頂点シェーダーをコンパイルする必要がある場合や、ネイティブ VS サポートなしで他の言語でコードを作成する必要がある場合など、多数のカスタム ビルド ツールを使用するプロジェクトも管理が容易になります。

ただし、構成ごとにビルド ツールの呼び出しを区別する必要があるため (たとえば、さまざまなコマンド ライン オプションを make に渡すなど)、さまざまな異なるプロジェクト構成が必要です。

すぐに思いつくマイナス面:

  • ビルドが遅い: VS は、外部ツールの呼び出しや、最初にプロジェクトをビルドする必要があるかどうかを判断することさえ特に迅速ではありません。
  • プロジェクト間の厄介な依存関係: 依存先が基本プロジェクトをビルドするようにセットアップするのは面倒であり、それらが正しい順序でビルドされることを確認するのは面倒です。私は SCons にこれを実行させることにある程度成功しましたが、うまく機能させることは常に課題です。
  • いくつかの便利な IDE 機能の喪失: 主な機能はエディット コンティニュです!

つまり、プロジェクト構成の管理に費やす時間が減り、Visual Studio が適切に動作するように誘導する時間が増えます。

于 2008-09-09T13:45:36.523 に答える
2

Visual Studio は、 MSBuild構成ファイルの上に構築されています。*proj および *sln ファイルは makefile と見なすことができます。ビルド プロセスを完全にカスタマイズできます。

于 2008-09-09T13:26:32.420 に答える
1

技術的には可能ですが、Visual Studio 内ではあまり使いやすいソリューションではありません。それはずっとあなたと戦っています。

NAntをご覧になることをお勧めします。基本的に必要なことは何でもできる、非常に堅牢なビルド システムです。

私たちの NAnt スクリプトは、すべてのビルドでこれを行います。

  1. データベースを最新バージョンに移行する
  2. データベースから C# エンティティを生成する
  3. 「マスター」ソリューションですべてのプロジェクトをコンパイルする
  4. すべての単体テストを実行する
  5. すべての統合テストを実行する

さらに、ビルド サーバーはこれを活用し、Sandcastle ドキュメントを生成するタスクを 1 つ追加します。

XML が気に入らない場合は、Rake (ruby)、Bake/BooBuildSystem (Boo)、またはPsake (PowerShell)も検討してください。

于 2008-09-09T13:28:36.500 に答える
0

あなたが説明しているものと同様の設定があります。少なくとも 3 つの異なるプラットフォームをサポートしているため、CMakeを使用してさまざまな Visual Studio ソリューションを管理できることがわかりました。セットアップは少し面倒かもしれませんが、基本的にはドキュメントといくつかのチュートリアルを読むだけです。プロジェクトとソリューションのプロパティに移動することで、できることは事実上すべて実行できるはずです。3 つのプラットフォーム ビルドすべてを同じソリューションに共存させることができるかどうかはわかりませんが、 CruiseControlを使用してビルドを管理し、必要に応じてテスト スクリプトを実行することができます。

于 2008-09-09T14:58:49.217 に答える
0

nant を使用してプロジェクトを個別にビルドし、ソリューションを置き換えて、1 つのコーディング ソリューションとビルド ソリューションを持たないようにすることができます。

1 つ注意すべき点は、vs 2005 以降のソリューションと csproj ファイルは msbuild スクリプトであることです。したがって、msbuild に慣れれば、既存のファイルを利用して vs を簡単にし、展開を簡単にすることができるかもしれません。

于 2008-09-09T13:26:41.357 に答える