4

サードパーティのライブラリをソース管理に保存する方法を尋ねる投稿があることは知っています ( thisやthisなど)。これらは素晴らしい答えですが、私はまだこれに対する答えを見つけることができません:

ライブラリが適切に動作するためにコンパイラ/IDE を変更する必要があるサードパーティのミドルウェア/フレームワーク バイナリをどのように保存しますか? 注: 必要に応じて、ミドルウェア ソースを保存する必要はありません。ヘッダー ファイル / lib / JAR のみを保存して、リンクする準備ができているようにします。

通常、ライブラリをアプリにリンクするだけで問題ありません。しかし、さらに必要なミドルウェア/フレームワークについてはどうでしょうか?

具体例:

  • Qt moc プリプロセッサ。

  • ZeroC Ice Slice (ice) コンパイラ (CORBA IDL プリプロセッサに類似)。

基本的に、これらのフレームワーク/ミドルウェアは、アプリケーションがリンクする前に独自のコードを生成する必要があります。

開発者の観点からは、理想的には、チェックアウトするだけで、すべての準備が整っている必要があります。しかし、私のIDE/コンパイラはまだ適切にセットアップされていないため、コンパイルは失敗します..

どう思いますか？

4

6 に答える 6

4

IDE、オペレーティングシステムなどのセットアップを含むすべてをバックアップします。これが私がすることです

1) すべてのサードパーティ ライブラリをソース管理に保存します。すべてのライブラリのブランチがあります。

2) ビルドに使用されたツール チェーン全体をバックアップします。これにはすべてのツールが含まれます。各ツールは各開発者コンピューターの同じディレクトリにインストールされるため、開発者コンピューターをリモートで簡単にセットアップできます。

3) これは最もハードコアですが、クリーンな完全な開発者用 IDE セットアップを 1 つ準備し、そこから VMWare / VirtualPC イメージを作成します。これは、将来インストーラーを動作させることができないと思われる場合に役立ちます。

適切にビルドされない Visual Studio 6 のコードをよく調べなければならないので、この教訓を苦痛な方法で学びました。

于 2009-10-14T02:03:21.213 に答える
2

より良い解決策は、別段の指示がない限り、ビルドが自己完結型であり、必要なすべてのソフトウェアをダウンロードできるようにすることだと思います。これは Maven の仕組みであり、非常に便利です。欠点は、アプリケーション サーバーなどをダウンロードする必要がある場合があり、これは非常に非現実的ですが、少なくともビルドは成功し、必要に応じてビルドを改善することが新しい開発者の責任になります。

もちろん、ソフトウェアが有人インストールを必要とする場合、これはうまく機能しませんが、いずれにしてもそのような依存関係を回避しようとします. 代替ルートを追加できます (たとえば、Eclipse がまだコードをコンパイルしていない場合は、ant スクリプトがコードをコンパイルします)。これが不可能な場合は、別のオプションとして、何が問題なのかを明確に示して失敗することです (たとえば、'CORBA_COMPILER_HOME' が設定されていません。設定してからやり直してください')。

とは言っても、もちろん、最も完全な解決策は、すべてをアプリに同梱することです (つまり、OS、IDE、作品)。しかし、それが一般的なケースに適用できるかどうかは疑問です。ビルドするためのそのタイプの要件についてどう思いますか?ソフトウェア製品？また、ソフトウェアを新しいプラットフォームに適応させたい人を制限します。

于 2009-10-23T12:28:20.343 に答える
1

更新:これは、IDE を変更する方法には実際には答えません。これは、C++/Python/Java の一種の Maven 代替品です。ビルドするために IDE を変更する必要はありません。その場合は、別の IDE または IDE ファイルを生成/変更するシステムが必要です。(クロスプラットフォームの c/c++ プロジェクト ファイル ジェネレーターについては、CMakeを参照してください。)

私はシステムを作成しました (最初は 2 つの異なる場所で Ant/Beanshell で、次に現在の仕事で Python で書き直しました)。サードパーティは (誰かによって) 個別にコンパイルされ、保存され、HTTP 経由で共有されます。

やや急ぎの説明は次のとおりです。

開始時に、ビルド システムはリポジトリ内のすべてのモジュールを調べ、各モジュールのセットアップ ターゲットを実行します。これにより、現在のコード リビジョンが使用するサードパーティ ライブラリまたはアプリの特定のバージョンがダウンロードされます。次に、これらが解凍され、PATH/INCLUDE などが追加され (または、小さなライブラリの場合は、現在のリポジトリの単一のディレクトリにコピーされ)、Visual Studio が /useenv で起動されます。

各モジュールのファイルは、必要なものをチェックし、Visual Studio、Matlab、Maya などのインストールとライセンスが必要な場合は、ローカル コンピューター上にある必要があります。それが存在しない場合、cmd ファイルは適切なエラー メッセージで失敗します。このようにして、正しいバージョンがそこにあることを確認することもできます

そのため、関係するローカル ディスクには多数のディレクトリがあります。%work% は、グローバル環境変数を使用して設定する必要があります。少なくとも重い C++ を実行している場合は、システムまたはソース チェックアウトとは別のディスクを使用することをお勧めします。

  • %work% <- すべての一時ファイル、解凍、および各作業コピーの一時ファイルのローカル ストア
  • %work%/_cache <- ダウンロードした zip (2 GB)
  • %work%/_local <- ローカル zip (開発用または旅行中に他の方法で取得するため)
  • %work%/_unzip <- _cache (10 GB) 内のファイルの解凍
  • %work%&_content <- テクスチャ/3D モデルおよびその他の大きなファイル (手動で同期、これは現在 5 GB で、VC にも適していません)
  • %work%/D_trunk/ <- d:/trunk にチェックアウトされた作業コピーの保存
  • %work%/E_branches/v2 <- e:/branches/v2 にチェックアウトされた作業コピーの保存

したがって、trunk が Boost 1.37 を使用し、branches/v2 が 1.39 を使用する場合、boost-1.39 と boost-1.37 の両方が /_cache/ (zip として) および /_unzip/ (raw ファイルとして) に存在します。

d:/trunk/BuildSystem/Visual Studio.cmd からのバット ファイルを使用して Visual Studio を起動すると、INCLUDE は /_unzip/boost-1.37 を指しますが、e:/branches/v2/BuildSystem/Visual Studio.cmd を実行すると、INCLUDE は /_unzip/boost-1.37 を指します。 /_unzip/boost-1.39.

リポジトリでは、小さなブートストラップ バイナリ セット (つまり、wget と 7z) のみを保存する必要があります。

現在、約 2 GB の圧縮データをダウンロードしており、これは 10 GB に解凍されます (pdb ファイルは巨大です!)。そのため、これをソース管理から除外することが不可欠です。このシステムを使用することで、SVN の代わりに Mercurial (または Git) などの DVCS を使用するのに十分なほどリポジトリのサイズを小さく保つことができます。これは非常に優れています。(個別に http サービスを提供するディレクトリの代わりに、Mercurials の bigfiles 拡張またはファイル共有を使用することを考えています。)

それは完璧に動作します。開発者は、チェックアウトし、ローカル キャッシュの環境変数を設定してから、リポジトリ内の特定のバッチ ファイルを介して Visual Studio を実行するだけです。解凍やコンパイルなどはありません。新しい開発者は、自分のコンピューターをすぐにセットアップできます。(Visual Studio のインストールには、桁違いに時間がかかります。)

初めて新しいコンピューターを使用するときは時間がかかりますが、その後はわずか数秒で完了します。ダウンロード/解凍はローカル コンピューターで共有されます。追加のブランチ/バージョンをチェックアウトしても、より多くのスペースを占有しません。オフラインでの作業も可能です。新しいファイルがアップロードされている場合は、zip ファイルを手動で取得するだけです。(このメカニズムは、サードパーティ ライブラリの新しいバージョン/コンパイルをテストするために不可欠です。)

基本はbitbucket のレポにありますが、公開する前にさらに作業が必要です。ドキュメントと磨きとは別に、次のことを計画しています。

  • 生のvcprojファイルの代わりにcmakeを使用するように拡張して、よりクロスプラットフォームにします。
  • サードパーティのパッケージのチェックアウト/ダウンロードから、それらのビルドと圧縮 (ダウンロードをローカル リポジトリに保存することを含む) までのプロセス全体をスクリプト化します...現在、それは私の開発コンピューターにあります。良くない。修正します。:)

moc に関しては、これを .vcproj ファイルに保存するQt の Visual Studio アドインを使用します。うまくいきます。私はCMakeがこれに対する最良の答えの1つであると思います

于 2009-10-24T10:30:58.587 に答える
1

ミドルウェアのビルド タスクを専用のビルド サーバーに外注し、バイナリ出力のみをソース管理下の通常のサード パーティの依存関係として含めます。

この戦略をうまく適用できるかどうかは、すべての開発者がミドルウェア コードを変更して頻繁に再コンパイルできる必要があるかどうかによって決まります。しかし、この問題は、プライベート ビルドを作成できる Teamcity のような継続的インテグレーション サーバーを介して解決することもできます。

ビルド プロセスは次のようになります。

  • ミドルウェア コードを含むミドルウェア リポジトリ
  • サーバーの構築、ミドルウェアの構築
  • ミドルウェアのビルド出力をサード パーティの参照としてプロジェクト リポジトリにプッシュする
于 2009-10-24T17:37:54.857 に答える
1

1ステップ追加するのはどうですか。

batファイルで起動するnantスクリプト。開発者は 1 つの .bat ファイルを実行するだけで済み、bat ファイルで nant を起動でき、Nant スクリプトで必要なことを実行できます。

于 2009-10-20T17:02:25.550 に答える
1

これは実際にはかなり微妙な質問です。ビルドを進めるために必要な環境の機能を管理する方法について話しています。この場合、それはコード ツールチェーンのトップ レベルですが、問題はツールチェーン全体、さらにはオペレーティング システムの主要な側面を含むように一般化できます。

私の職場では、コードが正常に実行される前に、基盤となるオペレーティング システムのさまざまな要件があります。これには、マシン固有の構成だけでなく、システム ライブラリと言語ランタイムの正しいバージョンが存在することも含まれます。これには、必要なツールチェーン要件を含む標準の汎用ビルド マシン イメージを維持することで対処しました。これを未使用のマシンにプッシュして、完全なツールチェーンと補助プログラムを含む基本的な環境を取得できます。

次に、fsvsを使用して追加の構成をバージョン管理し、必要に応じて特定のマシン グループに重ねることができます。

最後に、CI サーバー ( Hudsonを使用) にフックされたカスタム スクリプトを使用して、特定のプロジェクトに必要な前処理手順を実行します。

このアプローチの主な利点は次のとおりです。

  1. 開発者用マシンと本番用マシンを非常に簡単に構築してデプロイできます (そして、IT 部門にこの問題の側面を処理してもらいます)。
  2. 故障したマシンを簡単に交換できます。
  3. テスト用の既知の環境があります（ライブに移行する前に、シミュレートされた「本番サーバー」にすべてをインストールします）。
  4. 私たち (ソフトウェア チーム) は、重要な構成の詳細と明示的な前処理手順をバージョン管理します。
于 2009-10-20T21:28:19.397 に答える