0

ほとんどの人と同じように、サードパーティのライブラリを使用しています。多くは、VCS に保持しているソースを持っています。

現在、これらのライブラリが更新された場合、ソースを手動で取得してバイナリを再構築する必要があります。

代わりに、それらを使用するさまざまなソリューションからそれらを参照する方法を見つけようとしています。これにより、依存プロジェクトをプルするときにソース管理から自動的にプルされ、古い場合は自動的にビルドされます。また、提供されたソースを使用してデバッグできると便利です。

私が抱えている最初の問題は、ライブラリが依存プロジェクトと同じソリューション ルートにないことです。例えば。

\Libraries
 \External
  \Lib1
   Lib1.sln
\Products
 \Product1
  Product1.sln

ソリューションに追加しようとするLib1.csprojと、Product1次の警告が表示されます。

ソース管理に追加しようとしているプロジェクトが原因で、他のソース管理ユーザーがこのソリューションを開いたり、新しいバージョンを取得したりすることが困難になる場合があります。この問題を回避するには、ソリューション内の他のソース管理プロジェクトのバインディング ルート (C:\depot\Products\Products1) の下の場所からプロジェクトを追加します。

これを無視すれば、ビルドの依存関係を適切に設定できますが、それでもソース ツリー全体を一度にプルすることはできません。

特にソースコードがある場合、他の人がサードパーティのライブラリをどのようにセットアップしているのか疑問に思っていました。（Perforceを使用していますが、質問はどのVCSにも関連していると思います）

4

1 に答える 1

1

これを確実に解決する 1 つの方法は、再利用しようとしているすべてのモジュール/サードパーティ ソフトウェアを、"//shared" などの別の場所 (デポ) に配置することです。

製品 (SCMS / perforce のツリー) は、必要なモジュールをワークスペースにマッピングすることで「リンク」できます。強制的に、クライアントビューを介してそれを行うことができます。多くの人が多くの製品に取り組んでいる場合、製品の個人用ワークスペースを適切にセットアップするための簡単なメカニズムが必要になります (開発者が clientview を手動でセットアップする必要はありません)。これを達成するための 1 つの可能性は、ワークスペースをセットアップし、製品ルートにあるテンプレートに基づいて個人的な clientview を準備する小さな自作ツール/スクリプトであり、「//shared」デポのどのモジュールが必要かを定義します。クライアントワークスペースのどの場所にマップされるか。

私たちは何年も前からこの方法を使用しており、うまく機能しています。危険なのは、clientviews が非常に複雑になる可能性があることです。

于 2012-10-01T07:13:58.450 に答える