Boost.Config

使用缺省的 boost 配置

Boost 在發佈時已經針對最常用的編譯器和平台進行了配置；你應該可以"直接"使用 boost. 由於編譯器是獨立於標準庫進行配置的，所以即使你將編譯器的標準庫換為第三方的標準庫(如 STLport)，也還可以使用缺省的配置。

我們建議你"直接"使用 boost 而無需進行重配置。當然，只要你願意，你也可以運行配置腳本，而且我們也已經提供了回歸測試以便你在特定的編譯器設置下測試當前的 boost 配置。

Boost 庫的用戶可以通過訪問我們的 Tracker 和提交一份支持請求來要求增加對其它編譯器或平台的支持。

頭文件 <boost/config.hpp>

Boost 庫的實現通過以下方法來訪問與配置相關的宏

#include <boost/config.hpp>

雖然 Boost 庫的用戶不需要直接包含這個文件，也不需要使用這些配置宏，但是如果要用的話也是可以的。我們也提供了關於各個配置宏的用途、用法、限制的說明，以使得它們可以被 Boost 庫代碼及用戶代碼所使用。

Boost 的信息類或輔助類宏被設計為可供 Boost 用戶和我們本身內部使用。但是，特性測試類和缺陷測試類宏則被設計為只供 Boost 庫內使用，而不是給用戶代碼使用的，所以它們可能隨時被修改(不過不會被無故修改)。由修改配置宏所引起的 Boost 庫的問題可以通過 Boost 回歸測試來發現，所以 Boost 庫會為這些修改更新說明。作為對比，Boost 庫用戶的代碼也可能被這些宏的修改所影響，但卻沒有警告。在用戶代碼中保持跟上這些宏的修改的最好方法就是，隨時查閱在 Boost 開發者列表中的討論。

使用配置腳本

	重要
	本配置腳本只設置用於某個特定編譯器的 Boost 頭文件。它不影響 Boost.Build, 也不影響庫的構建。

如果你知道 boost 對於你的特定設置是錯誤配置的，而且你是在一個類UNIX的平台上，那麼你可能想試一下通過運行 boost 配置腳本來改善一下情況。你需要從在 shell 提示符下 cd 到 <boost-root>/libs/config/ 目錄中，並鍵入：

sh ./configure

你會看到一串檢查項，腳本正在進行回歸測試。注意，配置腳本只能在你的編譯器名為 g++, c++ 或 CC 的情況下進行自動檢測。如果你使用的是其它編譯器，你需要設置以下一個或多個環境變量：

變量	說明
CXX	編譯器的名字，如 `c++`.
CXXFLAGS	使用的編譯器開關，如 `-O2`.
LDFLAGS	使用的鏈接器開關，如 `-L/mypath`.
LIBS	要鏈接的庫，如 `-lpthread`.

例如，在 HP aCC 下運行該腳本，你應該使用：

export CXX="aCC"
export CXXFLAGS="-Aa -DAportable -D__HPACC_THREAD_SAFE_RB_TREE \
 -DRWSTD_MULTI_THREAD -DRW_MULTI_THREAD -D_REENTRANT -D_THREAD_SAFE"
export LDFLAGS="-DAportable"
export LIBS="-lpthread" 
sh ./configure

無論你用什麼方法運行這個配置腳本，當它結束時，你會發現一個新的頭文件 -user.hpp- 出現在 <boost-root>/libs/config/ 目錄中。注意，配置腳本缺省不會將這個頭文件安裝在你的 boost 包含路徑中。這個頭文件包含了由配置腳本生成的所有選項，再加一個頭文件節，其中包含有來自於缺省版本的 <boost/config/user.hpp>& nbsp;(位於 <boost-root>/boost/config/ 目錄)的用戶可設置選項。你有兩種方法來使用這個頭文件：

方法 1: 將這個頭文件複製到 <boost-root>/boost/config/ 以替換由 boost 提供的缺省 user.hpp. 這種方法只允許一個由配置腳本生成的設置；boost 開發者要避免使用這一方法，因為它有可能不小心將這個由配置生成的 <boost/config/user.hpp> 提交到 cvs 倉庫中(不會有人感謝你的！)。
方法 2: 給這個頭文件一個更易記的名字，並將它放在更方便的地方，然後定義宏 BOOST_USER_CONFIG 指向它。例如創建一個新的子目錄 <boost-root>/boost/config/user/, 並將頭文件複製到那兒；例如取名為 multithread-gcc-config.hpp. 然後在編譯時加上命令行選項： -DBOOST_USER_CONFIG="<boost/config/user/multithread-gcc-config.hpp>"，這樣 boost 就會使用新配置的頭文件。這種方法允許你生成一個以上的配置頭文件，並把它們與 boost 源程序分開 - 因此源程序的更新不會干擾你的配置。

用戶可設置的選項

有些配置選項代表了用戶的選擇，而不是編譯器的缺陷或平台的特定選項。它們被列於 <boost/config/user.hpp> 以及一個配置腳本生成的 user.hpp 頭文件的開始。你可以在命令行中定義它們，或者編輯 <boost/config/user.hpp>, 它們被列出在下表中：

宏	說明
`BOOST_USER_CONFIG`	如果被定義，它應在包含任意 boost 配置文件之前被定義為用戶配置文件的名字。如果未被定義，缺省為 `<boost/config/user.hpp>`.
`BOOST_COMPILER_CONFIG`	如果被定義，應為所用編譯器的配置文件名字。定義這個宏將中止編譯器選擇邏輯，並消除對包含該邏輯的頭文件的依賴。例如，如果你使用 gcc, 則你可以定義 BOOST_COMPILER_CONFIG 為 `<boost/config/compiler/gcc.hpp>`.
`BOOST_STDLIB_CONFIG`	如果被定義，應為所用標準庫的配置文件名字。定義這個宏將中止標準庫選擇邏輯，並消除對包含該邏輯的頭文件的依賴。例如，如果你使用 STLport, 則你可以定義 `BOOST_STDLIB_CONFIG` 為 `<boost/config/stdlib/stlport.hpp>`.
`BOOST_PLATFORM_CONFIG`	如果被定義，應為所用平台的配置文件名字。定義這個宏將中止平台選擇邏輯，並消除對包含該邏輯的頭文件的依賴。例如，如果你在 linux 上編譯，則你可以定義 `BOOST_PLATFORM_CONFIG` 為 `<boost/config/platform/linux.hpp>`.
`BOOST_NO_COMPILER_CONFIG`	如果被定義，則沒有任何編譯器配置文件被選擇或包含，當所用編譯器完全符合標準時定義該宏，或者已經在用戶頭文件(請見 `BOOST_USER_CONFIG`)中加入所需選項，例如通過一個 autoconf 生成的配置腳本。
`BOOST_NO_STDLIB_CONFIG`	如果被定義，則沒有任何標準庫配置文件被選擇或包含，當所用標準庫完全符合標準時定義該宏，或者已經在用戶頭文件(請見 `BOOST_USER_CONFIG`) 中加入所需選項，例如通過一個 autoconf 生成的配置腳本。
`BOOST_NO_PLATFORM_CONFIG`	如果被定義，則沒有任何平台配置文件被選擇或包含，當所用平台完全符合標準(且沒有其它可用特性)時定義該宏，或者已經在用戶頭文件(請見 `BOOST_USER_CONFIG`) 中加入所需選項，例如通過一個 autoconf 生成的配置腳本。
`BOOST_NO_CONFIG`	等同於定義了 `BOOST_NO_COMPILER_CONFIG`, `BOOST_NO_STDLIB_CONFIG` 和 `BOOST_NO_PLATFORM_CONFIG`.
`BOOST_STRICT_CONFIG`	在遇到比所知的最後版本更新的編譯器版本時，通常的做法是假設新版本與所知的最後版本具有相同的缺陷。如果定義了這個宏，則假設比所知最後版本更新的編譯器版本是完全符合標準的。這樣做對於 boost 開發者和測試者，以及那些想用 boost 來測試編譯器內部版本的人來說可能最適用。
`BOOST_ASSERT_CONFIG`	如果設置了這個標誌，則當配置發生未知事情時會以一個 #error 停止，不再繼續。Boost 回歸測試員應該定義這一標誌，那些想快速檢測出 boost 是否在他們的平台上得以支持的人也應該使用。
`BOOST_DISABLE_THREADS`	如果被定義，則關閉線程支持，即使當前所用編譯器支持多線程。
`BOOST_DISABLE_WIN32`	如果被定義，則關閉對 Win32 特定 API 的使用，即使它們可用。同時還具有與設置了 `BOOST_DISABLE_PTHREADS` 的相同效果，除非設置了 `BOOST_HAS_PTHREADS`. 該選項可以由配置系統自動設置，如果系統檢測到編譯器處於"strict模式"。
`BOOST_DISABLE_ABI_HEADERS`	讓 boost 不再包含任何前綴/後綴頭文件，對結構的壓縮和對齊進行通常的控制。
`BOOST_ABI_PREFIX`	包含一個前綴頭文件，替代 boost.config 的普通選擇，對結構的壓縮和對齊按需要進行設置。
`BOOST_ABI_SUFFIX`	包含一個後綴頭文件，替代 boost.config 的普通選擇，以恢復前綴頭文件的影響。
`BOOST_ALL_DYN_LINK`	強迫所有具有獨立源文件的庫在 Microsoft Windows 上鏈接為 dll 而不是靜態庫(該宏用於打開 `__declspec(dllimport)` 修改器，以便編譯器獲知要從一個 dll 中查找符號而不是從靜態庫查找)。注意，可能有些庫只能靜態鏈接(如 Boost.Test)，而另一些則只能動態鏈接(如 Boost.Threads)，這些該宏無效。
`BOOST_`WHATEVER`_DYN_LINK`	迫使庫在 Microsoft Windows 上"無論如何"都作為 dll 而不是靜態庫鏈接：要將宏名中的 WHATEVER 部分替換為要動態鏈接的庫名，例如，使用 `BOOST_DATE_TIME_DYN_LINK` 或 `BOOST_REGEX_DYN_LINK` 等(該宏用於打開 `__declspec(dllimport)` 修改器，以便編譯器獲知要從一個 dll 中查找符號而不是從靜態庫查找)。注意，可能有些庫只能靜態鏈接(如 Boost.Test)，而另一些則只能動態鏈接(如 Boost.Threads)，這些該宏不被支持。
`BOOST_ALL_NO_LIB`	通知配置系統不要自動選擇某些庫來鏈接。通常，如果一個編譯器支持 #pragma lib, 則正確的庫構建變量可以被自動選擇並鏈接，只要依據在庫的頭文件中包含的指令就可以了。該宏關閉這一特性。
`BOOST_`WHATEVER`_NO_LIB`	通知配置系統不要自動為"whatever"庫選擇要鏈接的庫，請將宏名中的 WHATEVER"替換為庫名；例如 `BOOST_DATE_TIME_NO_LIB` 或 `BOOST_REGEX_NO_LIB` 通常，如果一個編譯器支持 #pragma lib, 則正確的庫構建變量可以被自動選擇並鏈接，只要依據在庫的頭文件中包含的指令就可以了。該宏關閉這一特性。
`BOOST_LIB_DIAGNOSTIC`	讓自動鏈接代碼輸出診斷信息，以指示被選中進行鏈接的庫名。
`BOOST_LIB_TOOLSET`	覆蓋庫名中的 toolset 部分的名字；注意，如果定義了該宏，則必須定義為帶引號的字符串，如 "abc".

高級配置用法

例子 1, 創建我們自己的凍結配置
例子 2: 跳過你不需要的文件
例子 3: 使用配置腳本來凍結 boost 配置

通過在編譯器命令行設置不同的宏或者編輯 <boost/config/user.hpp>, 可以以不同的方法對 boost 配置進行設置。

Boost 的配置是結構化的，首先包含用戶配置文件(缺省為 <boost/config/user.hpp> 如果沒有定義 BOOST_USER_CONFIG)。它設置了用戶定義的策略，給機會用戶配置來影響後面所發生的事情。

接著應包含編譯器、標準庫和平台的配置文件。它們是通過宏來包含的(BOOST_COMPILER_CONFIG 等等，請見"用戶可設置宏")，如果對應的宏未被定義，則包含一個獨立的頭文件以檢測所用的是哪個編譯器/標準庫/平台，並設置它們。這個配置可以被告知完全忽略這些頭文件，如果設置了對應的 BOOST_NO_XXX 宏(例如，BOOST_NO_COMPILER_CONFIG 阻止包含任何編譯器配置文件 - 請見"用戶可設置宏")。

最後 boost 配置頭文件包含 <boost/config/suffix.hpp>; 該頭文件包括一些防護的配置代碼 - 例如某個 boost 宏被設置了，就意味著另一個宏也必須被設置。

以下用例僅僅表示了少量的可能性：

例子 1, 創建我們自己的凍結配置

假定我們用 Visual C++ 6 以及 STLport 4.0 來構建 boost. 我們也不打算再升級我們的編譯器和標準庫。為了避免在更新 boost 時破壞依賴關係，我們也許希望"凍結"我們的配置頭文件，那麼，我們就只需要在 boost 代碼本身有變化時重新構建我們的項目，而不需要因為 boost 對 Visual C++ 或 STLport 的最新版本所進行的配置修改而重新構建。我們先來弄明白要用的配置文件如下：編譯器配置文件 <boost/config/compiler/visualc.hpp>, 標準庫配置文件 <boost/config/stdlib/stlport.hpp>, 以及平台配置文件 <boost/config/platform/win32.hpp>. 接著我們創建自己的私有配置目錄： boost/config/mysetup/, 並將以上配置文件複製到該目錄下。最後，打開 <boost/config/user.hpp> 並編輯以下定義：

#define BOOST_COMPILER_CONFIG "boost/config/mysetup/visualc.hpp"
#define BOOST_STDLIB_CONFIG "boost/config/mysetup/stlport.hpp"
#define BOOST_USER_CONFIG "boost/config/mysetup/win32.hpp"

現在當你使用 boost, 它的配置頭文件將直接指向我們的"凍結"版本，而忽略缺省版本，現在你已經與升級 boost 所帶來的配置變化相隔離。如果你想修改某些 boost 配置文件，也可以使用這種方法；例如，你正工作在一個尚不被 boost 支持的編譯器測試版本上。

文件	說明
`config_info.cpp`	打印出你的編譯器/標準庫/平台設備的詳細描述，以及你當前的 boost 配置。該程序提供的信息在設置 boost 配置文件時非常有用。如果你想報告 boost 在你的編譯器/標準庫/平台上配置不正確，就請在報告所需變化時包含該程序的輸出。
`config_test.cpp`	一個包括了大多數單獨測試案例的集成測試程序。提供了快速的方法來檢查 boost 是否已針對你的編譯器/標準庫/平台正確配置。
`limits_test.cpp`	測試你的標準庫的 `std::numeric_limits` 實現(或它的 boost 替代物，如果定義了 `BOOST_NO_LIMITS`)。該測試程序對於多數版本的 numeric_limits 都會失敗，主要由於這些編譯器處理 NAN's 和無限大的方法。
`no_*pass.cpp`	單獨的編譯器缺陷測試文件。它們中的每一個都應該可以編譯，如果有一個不可以，則說明需要定義相應的 `BOOST_NO_XXX` 宏 - 詳情請見各個測試文件。
`no_*fail.cpp`	單獨的編譯器缺陷測試文件。它們中的每一個都應該不能通過編譯，如果有一個通過了，則說明相應的 `BOOST_NO_XXX` 在不需要定義時被定義了 - 詳情請見各個測試文件。
`has_*pass.cpp`	單獨的特性測試文件。如果其中某一個不能通過編譯，則說明相應的 `BOOST_HAS_XXX` 宏在不應該定義時被定義了 - 詳情請見各個測試文件。
`has_*fail.cpp`	單獨的特性測試文件。如果其中某一個通過了編譯，則說明相應的 `BOOST_HAS_XXX` 宏可以安全地被定義 - 詳情請見各個測試文件。

雖然你可以單獨運行配置回歸測試的各個測試文件，但是文件數量太多了，所以有些方便的方法可以幫助你：

如果你已經構建了 boost 回歸測試驅動程序，那麼你可以用它來生成一個漂亮的 html 格式的報告，其中包含所提供的測試文件的運行結果。

另一個方法是，你可以運行配置腳本，像這樣：

./configure --enable-test

這樣，該腳本將測試當前的配置而不是創建一個新的配置。

如果你要報告在某個新的平台/標準庫/編譯器上的測試結果，請包含完整的編譯器輸出日誌，以及 config_info.cpp 的輸出，還有測試的成功/失敗結果。

Boost.Config

Vesa Karvonen, John Maddock Beman Dawes

為你的平台配置 Boost