14

プロジェクト間で Delphi ソース ファイルを共有する最良の方法は何ですか?

明確化: 複数の Delphi プロジェクトで単一のソース ファイルを使用したいと考えています。SCM ツールを使用して同じファイルを複数のフォルダーに配置してきましたが、これは非常にエレガントなエクスペリエンスではなく、これをサポートしていないツールへの移行も検討しています。

この質問を調査してきたので、いくつかの異なるアプローチを検討しましたが、あなたが何をしているのか、どのようにアプローチを見つけているのか知りたいです.

重要なシナリオ:

  • コードタイム
    • 新しい共有依存関係を追加するには、共有が管理されるように、明示的な宣言が必要です。
    • 新しい共有依存関係の追加は比較的簡単です。複雑なプロセスは必要ありません。
      • プロジェクトの「インポートされた」ファイル (外部から) のすべてをリストする 1 つのファイルがよいでしょう。
  • コンパイル時
    • すべてのプロジェクトは、常に 1 つの現在のバージョン (ソースの同期状態とローカル編集の時点で最新) でビルドする必要があります。
      • (異なる場所で異なるバージョンを維持するには、ここではトピックではないファイル ブランチを使用する必要があります。)
    • 各プロジェクトが、異なるコンパイラ設定 (フラグを含む) で共有ファイルのコンパイルに影響を与えることができるかどうかは、議論の余地があります。
      • 常に一貫してビルドされているソース コードを維持する (つまり、長期的に) ことは間違いなく簡単です。
      • 変更の範囲を 1 つのプロジェクトに簡単に制限できる場合は、メンテナンス修正 (つまり、短期) を行う方がおそらく簡単です。
  • デバッグ時間
    • ルーチンにステップインするか、ブレークポイントを設定すると、正しいバージョンのソースが自動的に開きます。
    • 表示されたソースを編集すると、次のビルドに影響するはずです。
      • ソースの一時的なコピーに対してデバッグしたくありません。混乱の中でコードを失う可能性があります。

考慮事項:

  • 短期:
    • 最も簡単に導入できるアプローチはどれですか?
  • 長期：
    • 使用と保守が最も簡単なアプローチはどれですか?

フィードバックをお寄せいただきありがとうございます。

マティアス

- - アップデート - -

回答、コメント、投票を通じて、フィードバックをお寄せいただきありがとうございます。

私は、共有ファイルを 1 つの「生産者」プロジェクトに入れ、コンパイルされたファイルのリストを各「消費者」プロジェクトにインポートするという道を歩み始めました。プロジェクトは MSBuild と一緒にリンクされています。物事がより明確になったら、この質問と「ライブラリ プロジェクト」の回答を編集して、学んだことを共有します。

乞うご期待！(でも息を止めないでください。数分以内に窒息してしまいます! :P )

4

6 に答える 6

7

ソース管理システムのファイル共有機能を使用する

  • 長所: SCM システムがサポートしている場合、迅速かつ簡単にセットアップできます。
  • 長所/短所: 各消費者プロジェクトは、コンパイル時間に個別に影響を与える可能性があります。
  • 短所: ソースのローカル作業コピーには公式の場所がありません。
    • これは混乱を招く可能性があります。
  • 短所: ソースの変更は、チェックインして再取得するまで他の場所に反映されません。
    • チェックインする前に、他のプロジェクトを適切に検証することは可能ですが、お尻の王様の痛みです。
  • 短所: すべての SCM システムが共有ファイルをサポートしているわけではありません。
    • Subversion の最も近い機能は、フォルダー レベルの svn:externals です。

(編集: 混乱を避けるためにタイトルを変更しました。 もちろん、誰もがソース管理を使用する必要があります! :-) )

于 2008-11-03T19:39:03.650 に答える
3

ライブラリ プロジェクトを使用する

  • 長所: 編集する可能性がある各ファイルのコピーは 1 つだけです。
  • 利点: ソース ファイルごとに 1 回だけコンパイルします。
    • コンパイル時間が短縮されます。
    • 依存プロジェクト間の一貫したコンパイル。
    • 自然な増分ビルド。
  • 長所: デバッガーは自然に適切なソースにリンクします。
    • TODO: 確認します。
  • 長所/短所: コンシューマ プロジェクトは、コンパイル時間に個別に影響を与えることはできません。
  • 短所: ファイルごとのレベルで共有を管理するのが難しい場合があります。
    • TODO: 調査します。
  • 短所: セットアップに多大な労力がかかる可能性があります。
    • MSBuild プロジェクトのセットアップ。
    • 必要なプロジェクト設定を一元化し、これらの変更を検証する必要があります。
于 2008-11-03T19:42:58.883 に答える
1

質問を正しく理解したかどうかわかりません。とにかく、アプリケーションスイート（いくつかのプロジェクトですが、多くの一般的なコード）を構築するときは、次のようなフォルダー構造を作成します。

\Main
   \Project1
   \Project2
   ...
   \CommonUnits

関連するプロジェクトに共通のユニットを追加します（プロジェクトファイルと同じフォルダーにない場合でも）。さらに、小さなコードの違いには、プロジェクトレベルの条件付き定義（[プロジェクト]|[オプション]|[ディレクトリ/条件]）を使用する方が簡単な場合があります。たとえば、Project1には「APP_PROJECT1」のようなものが定義されており、共通の単位で$IFDEFを使用して特定のコードを記述できます。

重要なこと：この場合、スイート全体に対して1つのソース管理リポジトリを使用することをお勧めします（もちろん、ルートは\ Mainです）。

于 2008-11-17T11:02:41.730 に答える
1

特別な解決策は必要ないと思います。私たちのプロジェクト (コードの大部分を共有する複数のアプリケーション) では、次のアプローチを使用します。

  1. ソース コードをフォルダーに分割します。
  2. 共有コードの論理ユニットのパッケージを作成します。
  3. モノリス (パッケージを使用しない) と分割ビルドをサポートします。
  4. モノリス ビルドは、コーディングとデバッグに使用されます。各アプリケーションには独自の Unit 出力ディレクトリがあるため、それらはすべて個別にビルドされます。
  5. 依存関係の制限は、プロジェクトの検索パスによって適用されます。
  6. parted ビルドは自動的に作成されます (CruiseControl サーバーと MSBuild プロジェクトを使用します)。自動ビルドでは、ビルド前にすべての一時フォルダーがクリアされるため、連続するビルド間に依存関係はありません。

私たちの場合、インポートされたファイルのリストを制御できませんでした。ただし、parted ビルドでインポートされたパッケージのリストを制御できます。パッケージが小さいほど、粒度が高くなります。誰かが検索パスで利用できないフォルダーにあるユニットに依存関係を追加し、このユニットを含むパッケージが使用リストにない場合、parted ビルドは失敗します。そのため、依存関係を追加するには、明示的なアクション (parted ビルド用の CFG ファイルを生成する MSBuild スクリプトの変更) が必要です。

PS パッケージを使用して依存関係を制御するのではなく、大規模なアプリケーションを実行する Windows NT 以外のバージョンの問題のためです。したがって、依存関係の制御は副作用です。分割されたビルドは「リリース」と見なされ、モノリスは「デバッグ」構成と見なされます。モノリス アプリケーションは、コーディングとデバッグにのみ使用されます。開発者はモノリス アプリケーションを操作し、VCL デバッグ情報の添付、範囲チェック エラーのオンとオフの切り替え、最適化など、プロジェクト構成に独自の変更を加えます。ただし、SVN にコミットした後、CC は parted ビルドを作成しようとします。リポジトリから CFG ファイルを無視し、MSBuild プロジェクトの特別なタスクを使用して再作成します。したがって、依存関係に問題が発生していないことを確認できます (また、他のチェックも実行します)。

モノリス ビルドと分割ビルドを同時に必要としない限り、アプリケーションごとに 1 つのプロジェクトしかありません。MSBuild スクリプトで両方のバージョンをビルドする場合は、ターゲットをもう 1 つ追加し、CFG をもう一度再作成して、Unit 出力ディレクトリをもう 1 つ指定するだけです。当然、開発者が両方のバージョンを必要とする場合は、より多くのプロジェクトがある方が便利です。

于 2008-11-04T09:27:34.633 に答える
0

コピーオンコンパイル

  • 長所: ファイル共有はファイルごとに管理できます。
  • 長所/短所: 各消費者プロジェクトは、コンパイル時間に個別に影響を与える可能性があります。
  • 短所: デバッガーは、公式バージョンではなく、一時的なコピーにリンクします。
    • TODO: これを変更する方法がないかどうかを確認してください。
  • 短所: MSBuild プロジェクトのセットアップに多少の作業が必要になる場合があります。
  • 短所: 共有ファイルを段階的に構築するのが難しい場合があります。
    • Delphi の MSBuild ルールの一部を書き直す必要がある場合があります。
于 2008-11-03T19:40:30.980 に答える
0

コピー-コンパイル-削除

  • 長所: 編集する各ファイルの公式コピーは 1 つだけです。
  • 長所: デバッグ時に削除されているため、デバッガーは一時コピーにリンクしません。
    • TODO: 「Browsing Path」に配置した場合、デバッガーが元のソースを見つけることを確認します。
  • 長所: ファイル共有はファイルごとに管理できます。
  • 長所/短所: 各消費者プロジェクトは、コンパイル時間に個別に影響を与える可能性があります。
  • 短所: MSBuild プロジェクトのセットアップに多少の作業が必要になる場合があります。
  • 短所: 共有ファイルをインクリメンタルにビルドするのは難しい/不可能な場合があります。
    • Delphi の MSBuild ルールの一部を書き直す必要がある場合があります。
于 2008-11-03T19:41:36.297 に答える