私たちはBoostライブラリを持っています。これは決して変更されない膨大な数のファイルで構成され、そのうちのごく一部が使用されます。バージョンを変更している場合は、boostディレクトリ全体を交換します。現在、私たちはSVNのBoostソースをファイル単位で持っています。これはチェックアウト操作を非常に遅くします。特にWindowsではそうです。何かのように、ZIPファイル内のC++ファイルに対処するための表記/プラグインがあった場合、それはいいだろうg ++：ZIPファイルを入力として使用
：
// @ZIPFS ASSIGN 'boost' 'boost.zip/boost'
#include <boost/smart_ptr/shared_ptr.hpp>
はグラムでのコンパイラのフックに対するサポートはあります++？ 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 $<
私はこれについてあなたのmanページを尋ね、unzipコールの正確な構文を知りません。
他のMakeファイルでは、ソースファイルをコンパイルする前にmakeブーストを展開するために、ソースファイルをunpack_boostターゲットに依存させることができます。
# 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が動作するために厳密には必要ではありません。あなたはコマンドをunpack_boostターゲットに入れることができますが、ターゲットは効果的に偽ります。つまり、各ビルド中に実行されます。 inbetweenファイル（実際にはzipアーカイブにあるファイルで置き換える必要があります）は、unzipが必要な場合にのみ実行されるようにします。
これは、g ++でやっていないことです。これを実行する他のアプリケーションも変更する必要があるためです。
圧縮ファイルシステムにファイルを格納します。そして、すべてのアプリケーションが自動的に利益を得ます。
g ++がそのような「フック」されていない場合、アノテーションは無視され、zipは手動で（フォールバックとして）抽出できます。ブーストはこれについてすべて知る必要はありません。 2番目の：圧縮されたファイルシステムは、チェックアウトのスピードアップはしません。 – Notinlist
OSでは、ZIPファイル内のファイルに透過的にアクセスできるようにする必要があります。私は長い間前に自分のOSの設計に入れていたことを知っていますが（2004年前後）、それが使えるようになったことはありませんでした。欠点は、ZIP内のファイルで後方を探すことが圧縮されるにつれて遅くなることです（そして、圧縮器の状態を巻き戻せないので、代わりに最初から探す必要があります）。これはまた、巻き戻しおよび読み取りのためにゆっくりとしたジップ・イン・ジッパーを使用します。幸い、ほとんどの場合、ファイルを順番に読み込むだけです。
少なくともクライアント領域では、現在のOSにもリビルド可能である必要があります。使用されているファイルシステムアクセス関数（fopen、open、...）をフックし、特定のファイル名に対して自分のソフトウェアが返す一連の仮想ファイル記述子を追加することができます。それが実際のファイルであれば、それを渡します。もしそれが基礎ファイルをオープンしていなければ（おそらくこの関数を介して）、仮想ハンドルを渡します。ファイルの内容にアクセスするときは、キャッシュせずにzipファイルから直接読み取ります。
Linuxでは、LD_PRELOADを使用して（使用時に）既存のソフトウェアに注入します。Windowsでは、システムコールをフックするか、DLLをソフトウェアの領域に注入して同じ機能をフックできます。
これが既に存在するかどうかは誰にも分かりますか？私はそれがそうでない明確な理由を見ることができません...
LINUX上にFUSEカーネルモジュール（Filesystem User Space E-whatever）があります。 –
私たちは私たちの会社で同様の問題に直面してきました。ビルド環境でのブーストバージョンの管理は決して容易ではありません。 10人以上の開発者が、自分のシステムですべてのコーディングを行うと、何らかの自動化が必要になります。
まず、SVNやSCMシステムのブーストのような大きなライブラリのコピーを格納するのは良い考えではないと思います。ブーストでコードを変更する予定がある場合を除いて、それらのシステムは設計されていませんあなた自身。しかし、あなたがそれをやっていないと仮定しよう。
ここでは、さまざまな方法を試した後でこれを管理していますが、これは私たちにとって最適です。
使用するブーストのバージョンごとに、ツリー全体を解凍してファイルサーバーに配置し、コンパイルされたライブラリを置くアーキテクチャ/コンパイラの組み合わせごとに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
は、このディレクトリには、（ブースト/ * HPP。）ブースト・ツリーが含まれています は、我々はすべてのビルドシステム上でこれらのツリーのコピーを保存し、グローバルなシステム環境の中で、私たちのような変数を追加します
すべてのビルド構成（vsソリューション、vsプロパティファイル、gnuメイクファイルなど）は、内部変数を定義します（例：lib/win/x64/msvc2010/libboost_system * .lib、...） 、環境変数をインポートする：
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
ブーストのローカルコピーを保持する理由は、コンパイル速度です。それはかなりのディスクスペース、特にコンパイルされたライブラリを占めますが、ストレージは安く、開発者はコードをコンパイルするのに多くの時間を浪費しません。さらに、これは一度だけコピーする必要があります。
グローバル環境変数を使用する理由は、ビルド構成があるシステムから別のシステムに移転可能であるため、安全にSCMシステムにチェックインすることができるからです。
私たちは少しスムーズにするために、コピーと地球環境の設定を担当する小さなツールを開発しました。 CLIを使用すると、これをビルドプロセスに含めることもできます。
異なる作業環境は異なるルールと文化を意味しますが、私は多くのことを試しましたが、最終的には何らかの規則を定義することにしました。私たちはあなたにインスピレーションを与えるかもしれません...
これは、私たちがそれを行う方法と似ていますが、symlink boost /が存在する様々なブーストバージョンの1つにシンボリックリンクしています。 – KitsuneYMG
ファイルシステムがシンボリックリンクをサポートしていれば問題ありません。 Windowsと* nixシステムの両方で動作するメソッドが必要でした。 – Pat
1年前私はあなたと同じポジションにいました。私たちはソースをSVNに保存し、さらに悪いことに、同じリポジトリ（同じブランチ）を独自のコードとして追加しました。新鮮な作業コピーをチェックアウトするのに一日かかるので、複数のブランチで作業しようとするのは不可能でした。ブーストを別のベンダーリポジトリに移すことは助けになりましたが、チェックアウトにはまだ数時間かかるでしょう。
チームをgitに切り替えました。 SVNよりどれだけ優れているかを知るために、私はブースト1.45.0リリースを含むリポジトリを作成し、ネットワーク上にクローンしました。 （クローニングはすべてのリポジトリ履歴をコピーします（この場合は1回のコミットであり、作業コピーを作成します）。
クローンは6分かかりました。
最初の6秒で、リポジトリの圧縮されたコピーが自分のマシンにコピーされました。残りの時間は、それらの小さなファイルのすべてを書くことに費やされました。
gitを試してみることをお勧めします。学習曲線は急峻ですが、ブーストのコピーをクローンするのにかかる時間に、多くのプリコンパイラのハッキングが行われることは疑いの余地があります。
'g ++'を使っているのであれば、 'gzip'を使って一致させるのはなぜですか？ハハ悪い冗談、+1。 –
SVNから現代のSCMシステムに移行しますか？または、ブーストディレクトリをzipしてSVNに入れてチェックアウトを速くし、必要に応じてビルドプロセスの一部を解凍することもできます。 – bames53
@ bames53それについて考えてみましょう。多くの小さなファイルが抽出されるため、ウィンドウに時間を節約することはできません。確かに、それはやや良いでしょう。 – Notinlist