我們有Boost庫在我們身邊。它由大量的文件組成，這些文件永遠不會改變，只有很小的一部分被使用。如果我們正在更改版本，我們將交換整個boost目錄。目前我們在我們的SVN中有Boost源文件，這使得結帳操作非常緩慢，特別是在Windows上。g ++：使用ZIP文件作爲輸入
如果有一個符號/插件，以解決ZIP文件內的C++文件，像這將是很好：
// @ZIPFS ASSIGN 'boost' 'boost.zip/boost'
#include <boost/smart_ptr/shared_ptr.hpp>
是否有以g編譯掛鉤的任何++的支持？有關ZIP支持的努力嗎？其他想法？
我認爲make或類似的構建系統涉及構建軟件的過程。我會將zip文件放入存儲庫中，並在Makefile開始之前向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調用的確切語法，請問你的manpage關於這個。
然後在其他Makefiles中，您可以讓源文件依賴於unpack_boost目標，以便make在編譯源文件之前解壓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工作所必需的。您可以將unzip命令放入unpack_boost目標中，但目標實際上是假的，即：它將在每次構建期間執行。中間文件（當然，您需要用實際存在於zip壓縮文件中的文件替換）確保unzip只在必要時運行。
這是你不會在g ++中做的事情，因爲任何其他想要做它的應用程序也必須修改。
將文件存儲在壓縮文件系統中。然後每個應用程序自動獲得收益。
如果g ++沒有像那樣「掛鉤」，那麼註釋將被忽略，並且可以手動提取zip（作爲後備）。 Boost不需要知道這一切。第二：壓縮文件系統不會加速結帳。 – Notinlist
在操作系統中應該可以允許透明地訪問ZIP文件中的文件。我知道很久以前（2004年左右）我把它放在了我自己的操作系統的設計中，但從來沒有達到它可用的程度。不利的一面是，在壓縮文件中向後搜索文件的速度比壓縮文件慢（並且無法倒回壓縮器狀態，因此您必須從開始尋找）。這也使得使用拉鍊內拉鍊緩慢倒帶和閱讀。幸運的是，大多數情況下只是依次讀取文件。
對於當前的操作系統，至少在客戶端空間上也應該是可以改進的。您可以掛鉤使用的文件系統訪問函數（fopen，open，...）並添加一組虛擬文件描述符，您自己的軟件將返回給定文件名。如果它是一個真正的文件傳遞它，如果它不打開底層文件（可能再次通過這個非常功能）並傳遞一個虛擬句柄。在訪問文件內容時，直接從zip文件中讀取而不進行緩存。
在Linux上，您將使用LD_PRELOAD將其注入到現有軟件中（在使用時間），在Windows上，您可以掛接系統調用或將DLL注入軟件空間以掛接相同的函數。
有誰知道這是否已經存在？我看不出任何明確的理由，它不會...
在LINUX上有FUSE內核模塊（Filesystem User Space E-whatever）。 –
我們一直在我們公司面臨類似的問題。在構建環境中管理boost版本絕非易事。擁有10多個開發人員，所有編碼都在他們自己的系統上，您將需要某種自動化。首先，我認爲在SVN或任何SCM系統中存儲類似boost的大型庫的副本並不是一個好主意，但這不是這些系統設計的目的，除非您計劃在boost中修改代碼你自己。但讓我們假設你沒有這樣做。
下面是我們現在如何管理它，嘗試了很多不同的方法後，這對我們最有效。
對於我們使用的每種boost版本，我們將整個樹（解壓縮）放在一個文件服務器上，並且爲每個架構/編譯器組合添加額外的子目錄，其中放置編譯的庫。 我們保持每構建系統上這些樹的副本，並在全局系統環境中，我們添加變量一樣：
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）和所添加的預編譯庫（例如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
保留本地副本的原因是編譯速度。它佔用了相當多的磁盤空間，尤其是編譯後的庫，但是存儲成本低廉，而且開發人員不會花費大量時間編譯代碼。另外，這隻需要複製一次。
使用全局環境變量的原因是構建配置可以從一個系統轉移到另一個系統，因此可以安全地檢入您的SCM系統。
爲了使事情平滑一些，我們開發了一個小工具，負責複製和設置全球環境。使用CLI，甚至可以將其包含在構建過程中。
不同的工作環境意味着不同的規則和文化，但相信我，我們已經嘗試了很多東西，最後，我們決定定義某種約定。也許我們可以激勵你...
這與我們如何操作類似，除了我們將symlink boost /添加到存在的各種增強版本之外。 – KitsuneYMG
這很好，只要文件系統支持符號鏈接即可。我們需要一種適用於Windows和* nix系統的方法。 – Pat
一年前，我和你一樣處於同樣的位置。我們將源碼保存在SVN中，更糟糕的是，在與我們自己的代碼相同的存儲庫（同一分支）中包含了增強功能。嘗試在多個分支上工作是不可能的，因爲這需要大部分時間才能檢出新的工作副本。將推動力轉移到單獨的供應商存儲庫中有所幫助，但它仍需要花費數小時才能退出。
我把團隊轉到了git。爲了給你一個比SVN好多少的想法，我剛剛創建了一個包含boost 1.45.0版本的存儲庫，然後通過網絡克隆它。 （克隆複製所有存儲庫歷史記錄，在這種情況下是單次提交，並創建一個工作副本。）
該克隆耗時六分鐘。
在前六秒內，存儲庫的壓縮副本被複制到我的機器上。剩下的時間花在編寫所有這些小文件。
我衷心推薦你試試git。學習曲線非常陡峭，但是我懷疑你會在克隆一個boost副本所需的時間內完成很多預編譯器黑客工作。
如果您使用'g ++'，爲什麼不使用'gzip'來匹配？哈哈糟糕的笑話+1。 –
從SVN轉移到現代SCM系統？或者，您可以將boost目錄壓縮到SVN中，以便快速結帳，然後在必要時讓部分構建過程解壓縮該文件。 – bames53
@ bames53想到了。由於提取了許多小文件，它不會在Windows上節省太多時間。當然，這會更好一些。 – Notinlist