17

プロジェクト ファイルの編成には 2 つの主要な規則があり、その後に多くのバリエーションがあるようです。

規則 1: 高レベル タイプのディレクトリ、プロジェクトのサブディレクトリ

たとえば、wxWidgetsプロジェクトは次のスタイルを使用します。

/solution
   /bin
      /prj1
      /prj2
   /include
      /prj1
      /prj2
   /lib
      /prj1
      /prj2
   /src
      /prj1
      /prj2
   /test
      /prj1
      /prj2

長所：

  • プロジェクトの依存関係がある場合は、単一のファイルから管理できます
  • フラットビルドファイル構造

短所：

  • test には独自のヘッダー ファイルと cpp ファイルがあるため、ライブラリではなく EXE ファイルの単体テスト アプリケーションを生成する場合、テストするアプリケーションのオブジェクト ファイルを含める必要があります。これには、推論規則を作成し、すべてのソース ファイルの相対パスを展開する必要があります。
  • 別のソリューションでプロジェクトを再利用するには、ツリー構造から適切なファイルを抽出し、ビルド スクリプトを変更する必要があります。

規則 2: 高レベルのプロジェクト ディレクトリ、タイプ サブディレクトリ

たとえば、Wiresharkプロジェクトはこのスタイルを使用します

/solution
   /prj1
      /bin
      /include
      /lib
      /src
      /test
   /prj2
      /bin
      /include
      /lib
      /src
      /test

長所：

  • プロジェクト自体はフォルダー内に自己完結型であるため、移動や再利用が容易になります
  • ビルド ツールでより短い推論規則を使用できるようにします
  • 階層的なビルド スクリプトを容易にします

短所：

  • プロジェクト間に依存関係がある場合は、ビルド順序を管理するために、プロジェクト ディレクトリの上にビルド スクリプトのレイヤーを追加する必要があります。

現在、プロジェクトで規約 1 を使用していますが、これまでのところかなりうまく機能しています。現在、私は単体テストを (CxxTest を介して) 追加し、nmakeを使用して継続的インテグレーションへの移行を促進しています。規則 1 は、適切な nmake ファイルの作成に深刻な頭痛の種を引き起こしています。

私の主な要件/目標は次のとおりです。

  • ソリューション全体のビルド スクリプトを維持する労力のレベルを減らします。

  • ソリューション内のプロジェクトとそのビルド手順を他のプロジェクトから切り離します。

  • チェックアウト用のビルド スクリプトを使用して、コミットごとにメディア生成をリリースすることで、継続的な統合を促進します (もちろん、CruiseControl などの他のツールも活用します)。

  • 追加のプロジェクトまたはソース ファイルの追加または削除を、開発者にとって可能な限り簡単にし、エラーの発生を最小限に抑えます。

だから私は尋ねます：

  • これらの方法のいずれかの他の長所と短所はありますか?
  • これらの慣習の 1 つだけを支持する明確な反対意見はありますか?
4

2 に答える 2

4

【一部回答】

「規則2：高レベルのプロジェクトディレクトリ、サブディレクトリを入力」では、単一のコンは

プロジェクト間に依存関係がある場合は、ビルド順序を管理するために、プロジェクト ディレクトリの上にビルド スクリプトのレイヤーを追加する必要があります。

これは、多くのプロジェクトでプロと見なすこともできます。

反復的な一般的な定義が多数ある場合は、ソリューション全体の定数とパラメーターを定義できるビルド スクリプト用のインクルード ファイルが必要になるでしょう。そのため、(直接の) 依存関係がなくても、「ビルド スクリプトの追加レイヤー」が頻繁に発生します。

それは、構築においてよりモジュール化されたアプローチの余地がまだあるという点でプロです。一方、関連のない別のソリューションでプロジェクトを再利用する場合は、別の定義ファイルを作成する必要があります。(一方、コンベンション 1 のように、ソリューション全体に対して単一のビルド ファイルが存在する場合は、別のビルド スクリプトが必要になります。) メンテナンス要件に関しては、(IMO) プロジェクトに大きく依存します。

私の気持ちはコンベンション 2 に傾いていますが、明確な勝利には程遠いです。実際、最近までうまく機能していたコンベンション 1 での経験は、すべての中で最大の長所かもしれません。特定の組織での経験を持つ人々のチームは貴重な資産です。

于 2008-11-06T07:53:28.317 に答える
1

一度に両方の組織を持つことができるように、NTFS ジャンクション ポイントの使用を検討してください。簡単な定義: 「ジャンクション ポイントは Microsoft のシンボリック リンクの実装ですが、ディレクトリに対してのみ機能します。」

プロジェクトを簡単に移動できるようにするため、「実際の」レイアウトには規約 2 を使用します。次に、規約 1 のビューを作成します。

mkdir /solution/test
linkd /solution/test/prj1 /solution/prj1/test
linkd /solution/test/prj2 /solution/prj2/test

今、あなたは...

/solution
  /test
    /prj1
    /prj2

...これは望ましい結果でした。

有益であると判断した場合は、/src または他のディレクトリに対して同じことを行うことができます。規則 1 のビューを活用するテスト スクリプトは、/solution/test にあります。

于 2008-11-06T12:23:18.117 に答える