50個近くあるVCプロジェクトからなるソリューションがあり、
この中には多くのアプリケーションや共通ライブラリなどが含まれています。
このうち、共通ライブラリへの機能追加やバグ修正を行っている最中は、
これに依存している部分がすべてビルド対象になってしまい、
未完成状態のときに無駄にビルド時間が長くなってしまいます。
こういう操作を扱う場合、どのように管理するのが的確なのでしょうか。
(1)
共通ライブラリを動かせるだけの最小限のプロジェクト以外をアンロードして、
共通ライブラリが安定してきたらすべてロードし直す
(2)
共通ライブラリを動かせるだけの最小限のビルド構成を別途作っておいて、
機能追加やバグ修正を行っている間はその構成に切り替える
1の方法だと、毎回ソリューションエクスプローラで
プロジェクトのロードやアンロードを繰り返す必要があるでしょうし、
アンロードするプロジェクトを間違えるというミスも多発しそうです。
2の方法だと、この先さらにプロジェクトを追加するたびに
様々なビルド構成を再設定する操作が必要になりそうです。
皆さんはどのように管理されていますでしょうか。
昔、他社製作の超巨大プロジェクトで、ソースコード数も数100と言う
よくもまぁ〜作ったものだと思うものの修正や機能追加を行ったこと
がありました。（実際にソースコード量は、約2GB・・・ありえん）
コンパイルにも何時間もかかるものだったので、機能別ライブラリに
ソリューションを分割し、プロジェクト管理しましたが、わざわざ、
１個のソリューションに押し込めることは無いのでは？と思います。
プロジェクトを参照設定するものや、DLLを直接参照設定するもの。
と、デバッグ／リリース用と細かく細分化したソリューションにして
やることで、よいのでは？
ソリューションの選択ミスもありますが、その点は誰にだって間違い
はあるので、回避できない問題はどうしてもあると思います。
間違いが起きにくいソリューション・プロジェクトの階層構造を構築
するのと、それに適したＨＤＤ上のフォルダの階層構造をうまく作る
ことで、ミスは最小限に抑えられると考えます。
以上。
一般には「共通部分をDLL化する」が正解です。
当然ですが、ヘッダーに変更が入ってしまうと、
参照している全てのプロジェクトに影響が出てしまいます。
従って、この共通部分はメインのソリューションとは
別のソリューションとプロジェクトに分離します。
実行ファイルをビルドするための、メインの各ソリューションでは、
当該の共通部分のプロジェクトをソリューションに含ませません。
コピーされた、共通部分のヘッダーファイル群のインクルードと、
エクスポートライブラリへの、リンクを行うだけにします。
共通部分のソリューションが、正式リリースになるまでは、
共通ヘッダーとライブラリは、メインのソリューションの
参照するホルダにコピーしないようにします。
このようにすると、メイン側は共通部分が正式リリースになるまで
被害は受けません。共通部分が正式リリースされても、ヘッダーに
変化が無ければリンクだけで済みます。
また、共通部分の担当者は、もっとずっと軽いメインを使用して、
デバッグを進めるべきでしょう。
ちなみに、自分が日常的に担当してるのは、共通部分が、
500ファイル程度。メインソリューションが、5ソリューション、
総ファイル数は5000ファイル程度で、比較的コードが
多いほうだと思いますが、べつに困ったことはありません。
ありがとうございます。
参考にさせていただきます。