Boost C++ Libraries Home Libraries People FAQ More

Next

Boost.Config

Vesa Karvonen, John Maddock Beman Dawes

Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)


目錄

為 你的平台配置 Boost
使 用缺省的 boost 配置
頭 文件 <boost/config.hpp>
使 用配置腳本
用 戶可設置的選項
高 級配置用法
測 試 boost 配置
Boost Macro 參考
描 述缺陷的宏
描 述可選特性的宏
描述可能的 C++0x 特性的宏
描述不被支持的 C++0x 特性的宏
Boost 輔助宏
Boost 信息宏
用 於分隔源代碼的宏
給 Boost 作者的指引
禁止編譯器警告
增 加新的缺陷宏
增 加新的特性測試宏
修 改 Boost 配置頭文件
原理
問 題
解 決方法
鳴謝

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

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

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


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

#include <boost/config.hpp>

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

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

[Important] 重要

本配置腳本只設置用於某個特定編譯器的 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_CONFIGBOOST_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_LINKBOOST_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_LIBBOOST_REGEX_NO_LIB
通常,如果一個編譯器支持 #pragma lib, 則正確的庫構建變量可以被自動選擇並鏈接,只要依據在庫的頭文件中包含的指令就可以了。該宏關閉這一特性。

BOOST_LIB_DIAGNOSTIC

讓自動鏈接代碼輸出診斷信息,以指示被選中進行鏈接的庫名。

BOOST_LIB_TOOLSET

覆蓋庫名中的 toolset 部分的名字;注意,如果定義了該宏,則必須定義為帶引號的字符串,如 "abc".

通過在編譯器命令行設置不同的宏或者編輯 <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 宏被設置了,就意味著另一個宏也必須被設置。

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

假定我們用 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 支持的編譯器測試版本上。

假定你正在一個完全符合標準的編譯器上使用 boost; 你不關心你的編譯器的舊版本是否存在缺陷,因為你知道當前所用的版本不需要任何配置宏的設置。在這種情況下,你可以在命令行或 <boost/config/user.hpp> 中定義 BOOST_NO_COMPILER_CONFIG, 完全跳過編譯器配置文件(實際上你跳過了兩個頭文件,一個是檢測編譯器類型的,另一個是用於配置 boost 的)。這有兩個結果:一是可以編譯更少的代碼,二是消除了對兩個 boost 頭文件的依賴性。

如果你工作在一個類unix的平台,那麼你可以使用配置腳本來根據你當前的編譯器設置生成一個"凍結"的配置 - 詳情 請見"使用配置腳本"

boost 配置庫提供了一整套回歸測試程序,它們位於 <boost-root>/boost/config/ test/ 子目錄下:

文件

說明

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 的輸出,還有測試的成功/失敗結果。

Last revised: October 27, 2008 at 16:15:55 GMT


Next