私たちの側にはBoostライブラリがあります。変更されることのない膨大な数のファイルで構成されており、使用されるのはごく一部です。バージョンを変更する場合は、ブーストディレクトリ全体を交換します。現在、SVNにはファイルごとにBoostソースがあり、特にWindowsではチェックアウト操作が非常に遅くなります。
次のような、ZIPファイル内のC++ファイルをアドレス指定するための表記法/プラグインがあると便利です。
// @ZIPFS ASSIGN 'boost' 'boost.zip/boost'
#include <boost/smart_ptr/shared_ptr.hpp>
g ++でコンパイラフックをサポートしていますか？ZIPサポートに関して何か努力はありますか？他のアイデア？
または同様のビルドmakeシステムがソフトウェアのビルドプロセスに関与していると思います。zipファイルをリポジトリに配置し、実際のビルドが開始される前にそれを抽出するルールをMakefileに追加します。
たとえば、zipファイルがソースツリーの「external / boost.zip」にあり、「external / boost」に抽出され、その最上位にファイル「boost_version.h」が含まれているとします。
# external/Makefile
unpack_boost: boost/boost_version.h
boost/boost_version.h: boost.zip
unzip $<
呼び出しの正確な構文がわかりませんunzip。これについては、マンページに問い合わせてください。
次に、他のMakefileで、ソースファイルをコンパイルする前にBoostunpack_boostを解凍するために、ソースファイルをターゲットに依存させることができます。make
# src/Makefile (excerpt)
unpack_boost:
make -C ../external unpack_boost
source_file.cpp: unpack_boost
Makefileジェネレーター（またはまったく異なるビルドシステム）を使用している場合は、カスタムターゲットのようなものを作成する方法について、これらのプログラムのドキュメントを確認してくださいunpack_boost。たとえば、CMakeでは、add_custom_commandディレクティブを使用できます。
細字：boost/boost_version.h Makefileが機能するためにファイルが厳密に必要なわけではありません。unzipコマンドをターゲットに入れることもできますがunpack_boost、その場合、ターゲットは事実上偽物になります。つまり、ビルドごとに実行されます。中間のファイル（もちろん、zipアーカイブに実際に存在するファイルに置き換える必要があります）はunzip、必要な場合にのみ実行されることを保証します。
一年前、私はあなたと同じ立場にいました。ソースをSVNに保持し、さらに悪いことに、独自のコードと同じリポジトリ（同じブランチ）にブーストを含めました。新しい作業コピーをチェックアウトするのにほとんどの日がかかるため、複数のブランチで作業することは不可能でした。Boostを別のベンダーリポジトリに移動することは役に立ちましたが、それでもチェックアウトには数時間かかります。
チームをgitに切り替えました。SVNよりもはるかに優れていることを理解するために、Boost 1.45.0リリースを含むリポジトリを作成し、ネットワーク経由でクローンを作成しました。（クローンを作成すると、すべてのリポジトリ履歴がコピーされます。この場合は1回のコミットであり、作業コピーが作成されます。）
そのクローンは6分かかりました。
最初の6秒間で、リポジトリの圧縮コピーが私のマシンにコピーされました。残りの時間は、これらの小さなファイルをすべて書き込むために費やされました。
gitを試してみることを心からお勧めします。学習曲線は急ですが、ブーストのコピーを複製するのにかかる時間内に、プリコンパイラーのハッキングが多く行われるとは思えません。
私たちの会社でも同様の問題に直面しています。ビルド環境でのブーストバージョンの管理は決して簡単ではありません。10人以上の開発者がいて、すべてが独自のシステムでコーディングしているため、何らかの自動化が必要になります。
まず、ブーストのような大きなライブラリのコピーをSVNやSCMシステムに保存するのは良い考えではないと思います。ブーストでコードを変更する場合を除いて、これらのシステムはそのために設計されたものではありません。しかし、あなたがそれをしていないと仮定しましょう。
これが私たちが今それを管理する方法です、多くの異なる方法を試した後、これは私たちにとって最もうまくいきます。
使用するBoostのバージョンごとに、ツリー全体（解凍済み）をファイルサーバーに配置し、アーキテクチャ/コンパイラの組み合わせごとに1つずつ、コンパイル済みライブラリを配置するサブディレクトリを追加します。これらのツリーのコピーをすべてのビルドシステムに保持し、グローバルシステム環境で次のような変数を追加します。
BOOST_1_48=C:\boost\1.48 # Windows environment var
また
BOOST_1_48=/usr/local/boost/1.48 # Linux environment var, e.g. in /etc/profile.d/boost.sh
このディレクトリには、ブーストツリー（boost / *。hpp）と追加されたプリコンパイル済みライブラリ（例：lib / win / x64 / msvc2010 / libboost_system * .lib、...）が含まれています。
すべてのビルド構成（vsソリューション、vsプロパティファイル、gnu makefiles、...）は、内部変数を定義し、次のような環境変数をインポートします。
BOOSTROOT=$(BOOST_1_48) # e.g. in a Makefile, or an included Makefile
さらにビルドルールはすべて、インクルードパスとライブラリ検索パスを定義するためにBOOSTROOT設定を使用します。
CXXFLAGS += -I$(BOOSTROOT)
LFLAGS += -L$(BOOSTROOT)/lib/linux/x64/ubuntu/precise
LFLAGS += -lboost_date_time
Boostのローカルコピーを保持する理由は、コンパイル速度です。それはかなりのディスクスペース、特にコンパイルされたライブラリを消費しますが、ストレージは安価であり、開発者がコードのコンパイルに多くの時間を失うことはありません。さらに、これは一度だけコピーする必要があります。
グローバル環境変数を使用する理由は、ビルド構成をあるシステムから別のシステムに転送できるため、SCMシステムに安全にチェックインできるためです。
少しスムーズにするために、地球環境のコピーと設定を処理する小さなツールを開発しました。CLIを使用すると、これをビルドプロセスに含めることもできます。
作業環境が異なれば、ルールや文化も異なりますが、私は多くのことを試し、最終的に、ある種の規則を定義することにしました。多分私たちのものはあなたにインスピレーションを与えることができます...
OSでは、ZIPファイル内のファイルへの透過的なアクセスを許可できる必要があります。ずっと前（2004年頃）に自分のOSの設計に取り入れたことは知っていますが、使えるようになるまでには至りませんでした。欠点は、ZIP内のファイルを逆方向にシークするのが圧縮されるため遅くなることです（コンプレッサーの状態を巻き戻すことができないため、代わりに最初からシークする必要があります）。これにより、zip-inside-a-zipの巻き戻しと読み取りが遅くなります。幸い、ほとんどの場合、ファイルを順番に読み取るだけです。
また、少なくともクライアントスペースでは、現在のOSに後付けできる必要があります。使用するファイルシステムアクセス関数（fopen、open、...）をフックして、独自のソフトウェアが特定のファイル名に対して返す仮想ファイル記述子のセットを追加できます。それが実際のファイルである場合は、それを渡すだけです。基になるファイルが開かれていない場合は（おそらく、この関数を介して）、仮想ハンドルを渡します。ファイルの内容にアクセスするときは、キャッシュせずにzipファイルから直接読み取ってください。
Linuxでは、LD_PRELOADを使用して既存のソフトウェアに（使用時に）挿入します。Windowsでは、システムコールをフックするか、ソフトウェアのスペースにDLLを挿入して、同じ機能をフックします。
これがすでに存在するかどうか誰かが知っていますか？私はそれがそうしない明確な理由を見ることができません...
これは、g ++では実行しないことです。これを実行したい他のアプリケーションも、変更する必要があるためです。
圧縮ファイルシステムにファイルを保存します。その後、すべてのアプリケーションが自動的にメリットを享受します。