Visual Studio (2005) でソリューション/プロジェクト ファイルの代わりに Makefile を使用する

Question

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

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

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

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

ただし、私は Visual Studio での Makefile の経験がありません。他の人が経験や問題を共有できるかどうか知りたいと思っています。

ありがとう。

(投稿を編集して、これらが C++ ビルドであることを言及しました)

Answer 1

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

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

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

すぐに思い浮かぶ欠点は次のとおりです。

• ビルドが遅い場合:VS は、外部ツールを呼び出すことや、そもそもプロジェクトをビルドする必要があるかどうかを判断することさえそれほど迅速ではありません。
• 厄介なプロジェクト間の依存関係:依存関係者が基本プロジェクトをビルドするように設定するのは面倒ですが、正しい順序でビルドされるようにするのはさらに面倒です。私は SCons にこれをやらせることにある程度の成功を収めてきましたが、うまく機能させるのは常に困難です。
• いくつかの便利な IDE 機能が失われます。エディット＆コンティニューがメインです！

つまり、プロジェクト構成の管理に費やす時間が減り、Visual Studio が適切に動作するよう説得することに多くの時間を費やすことになります。

Answer 2

Visual Studio は、 MSBuild 構成ファイル。*proj ファイルと *sln ファイルをメイクファイルと見なすことができます。これらを使用すると、ビルド プロセスを完全にカスタマイズできます。

Answer 3

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

見てみることをお勧めします NAnt. 。これは非常に堅牢なビルド システムであり、基本的に必要なことはすべて実行できます。

NAnt スクリプトはすべてのビルドでこれを実行します。

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

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

XML が好きではない場合は、以下も参照してください。 レーキ (ルビ)、 ベイク/ブービルドシステム (ブー)、または プサケ （パワーシェル）

Answer 4

nant を使用してプロジェクトを個別にビルドすることでソリューションを置き換えることができ、コーディング ソリューションは 1 つでビルド ソリューションはありません。

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

Answer 5

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