2

私は Visual Studio 2010 ソリューションを持っています。これには、4 つの異なるサードパーティ ライブラリとヘッダーを含める必要があります。これらのサードパーティの依存関係は、含まれる前に個別にインストールされます。そのため、ヘッダーとライブラリのインクルード パスはマシンによって異なります。

今、私が望んでいるのは、さまざまな開発者がさまざまなマシンで自分のソリューションを構築して、これらのツールのパスに含まれる依存関係を最小限の作業でよりスムーズに含めることです。

私は次の解決策に出くわしました：

  1. 環境変数の使用 (これらの環境変数を使用する前に、これらのツールのインクルード パスが正しく設定される前に、環境変数をプリプロセッサ ステートメントとして作成するにはどうすればよいですか)

  2. プロパティ ページの使用 (ソリューションをビルドする前にこれらのツールがセットアップされている場合、これらのツールのパスをマクロとして追加し、ビルドするすべてのマシンで使用できるようにするにはどうすればよいですか)

他の解決策???

これは、複数の開発者がサードパーティ ツールのライブラリとヘッダーを異なる開発者のマシンの異なるパスにインストールして同じソリューションを共有/使用するという一般的な問題であるため、より良い解決策が必要であることはわかっています。

編集: Boost ライブラリ、OpenSSL、および他の 2 つの特定のサードパーティ ツールを使用していますが、これらはすべて私のソリューションのバージョンに大きく依存しています。

上記のライブラリのさまざまなバージョンを使用するさまざまなソース ブランチがあります。また、ライブラリとヘッダーを共有する他のソリューションもあります。したがって、これらのライブラリは冗長であるため、すべてのソリューション ディレクトリにコピーしても意味がありません。

したがって、それらを1つの共通の場所に配置し、異なるプロジェクト/ソリューションにリンクし、これらのライブラリの異なるインストール/場所パスからリンクすることが私の最終的な目標です。

4

4 に答える 4

0

別の解決策は、シンボリックリンクを使用することです。したがって、プロジェクトの観点からは、そのマシンは他のマシンと同じディレクトリ構造を持っているように見えます。ただし、これを行うことはお勧めしませんが、すぐに混乱する可能性があります。すべてをCに置くとすると、開発者の1人がCドライブのないマシンを持っていると困惑します。

さらに別の解決策は、ビルドに必要なすべてのものをリポジトリに保存するなどして、すべてのマシンがまったく同じディレクトリ構造を使用するようにすることです。ただし、プロジェクトでこれらのディレクトリへの絶対パスを使用している場合は特に、これは多少制限される可能性があります。

あなたが与える2番目の解決策は、最良の解決策ではないにしても、実際にはかなり良いものです。一般的な使用法は、ソースツリーにworkspace.props.templateのようなものを提供することです。これは、 workspace.propsに名前を変更し、ユーザーが（または自動ツール/バッチスクリプト/ ...）変更して正しいものを含める必要があります。パス。私たちはいつもこれを使っています、そしてそれは非常に便利です。また、絶対パスのみがプロパティシートに入るので、同じマシン上に異なる独立したビルドツリーを簡単にセットアップできます。

于 2011-04-25T07:11:45.173 に答える
0

探している間接化にはプロパティ (*.vsprops) ファイルを使用することをお勧めします。

開発者が自分のマシンの好きな場所にツールをインストールしたようです。そのためvsprops、それぞれのファイルを作成できるはずですが、標準の場所に保存されます。 VS プロジェクト ファイルには、これらすべての vsprops ファイルを含める必要があります。これは、ソース管理がバージョン管理外の 4 つのファイルを効果的に参照していることを意味します。

もちろん、最終的には、開発者にサードパーティ ツールを自分のマシンの同じ場所にインストールしてもらうか (これらのツールの新しいバージョンが登場するたびに段階的に行うことができます)、ツールのヘッダーとライブラリ ファイルを次の場所に含める必要があります。ソース管理。

于 2011-04-25T09:25:27.833 に答える
0

私たちも職場で同様の状況にあり、それはお尻の痛みです。現在、すべてのサードパーティのライブラリとヘッダーをリポジトリのサードパーティのサブフォルダーに配置するように移行しています。このようにして、それらは常に同じ場所にあり、誰もが同じバージョンに対してビルドしているため、古いブランチをビルドする必要がある場合は、ブランチに切り替えるときに、正しいライブラリ バージョンを自動的に取得します。それが最善の方法だと思います - それ以外はすべて頭痛の種です。

于 2011-04-25T07:06:32.907 に答える
0

これらのサードパーティの依存関係は、含まれる前に個別にインストールされます。そのため、ヘッダーとライブラリのインクルード パスはマシンによって異なります。

2 番目のステートメントは、最初のステートメントの後に続くものではありません。なぜそれらは必然的に異なるパスにあるのですか？

環境変数の使用 (これらの環境変数を使用する前に、これらのツールのインクルード パスが正しく設定される前に、環境変数をプリプロセッサ ステートメントとして作成するにはどうすればよいですか)

VC++ では、ビルド前のアクションをいくつでも定義できます。set コマンドを使用して環境変数を直接設定するか、set コマンドを含むバッチ ファイルを呼び出すことができます。後者は、すべての開発者が共通のプロジェクト ファイルを持ち、環境に合わせてバッチ ファイルを変更するだけでよく、もちろんバッチ ファイルには任意の数のコマンドを含めることができるため、後者が望ましい場合があります。

他の解決策???

個人的には、すべてのライブラリの依存関係をプロジェクト自体のサブディレクトリに移動し、開発者がライブラリを任意の場所に個別にインストールするのではなく、開発者が利用できるようにします。さらに、すべてをバージョン管理システムにチェックインして、進行中の作業とライブラリの更新の制御された共有と更新を可能にします。

それらはプロジェクトのサブフォルダーにある必要はありませんが、たとえば、外部ライブラリの異なるバージョンを使用する複数のプロジェクト (または同じプロジェクトの異なるリビジョンまたはブランチ) が同時にチェックアウトされている場合、これはより安全です。

于 2011-04-25T07:09:57.083 に答える