版权所有 © 2001-2007 Beman Dawes, Vesa Karvonen, John Maddock
根据 Boost 软件许可证版本 1.0 发布。(参见随附文件 LICENSE_1_0.txt 或在 https://boost.ac.cn/LICENSE_1_0.txt 复制)
Boost 已经为大多数常见的编译器和平台进行了配置;您应该能够“按原样”使用 boost。由于编译器与标准库是分开配置的,即使您用第三方标准库(如 STLport)替换了编译器的标准库,默认配置也应该能正常工作。
建议使用 Boost 的方法是“按原样”使用,而不尝试重新配置。当然,如果您愿意,也可以运行 configure 脚本,并且提供了回归测试,允许您使用特定编译器设置测试当前的 Boost 配置。
Boost 库用户可以通过访问我们的 Github 并提交支持请求来请求支持额外的编译器或平台。
Boost 库实现通过以下方式访问配置宏:
#include <boost/config.hpp>
虽然 Boost 库用户不一定需要直接包含该文件,或使用这些配置宏,但这样做是可以接受的。配置宏已记录了其目的、用法和限制,使其可供 Boost 库和用户代码使用。
Boost 的 信息宏 或 辅助宏 是为 Boost 用户以及我们内部使用而设计的。但请注意,功能测试宏 和 缺陷测试宏 是为 Boost 库内部使用而设计的,并非用户代码,因此它们可能会随时更改(尽管不会进行无故更改)。由配置宏更改引起的 Boost 库问题会在 Boost 回归测试中捕获,因此 Boost 库会更新以适应这些更改。相比之下,Boost 库用户代码可能会在不发出警告的情况下受到宏更改的不利影响。及时了解用户代码中使用的宏的更改的最佳方法是关注 Boost 开发者列表上的讨论。
![]() |
重要提示 |
|---|---|
此 configure 脚本仅设置 Boost 头文件以供特定编译器使用。它对 Boost.Build 或库的构建方式没有影响。 |
如果您发现 Boost 为您的特定设置配置不正确,并且您使用的是类 Unix 平台,那么您可能想尝试运行 Boost configure 脚本来改进这一点。从 shell 命令提示符,您需要 `cd` 进入 <boost-root>/libs/config/ 并输入
sh ./configure
您将看到脚本在执行回归测试时正在检查的项目列表。请注意,configure 脚本实际上只会自动检测您的编译器,前提是它被命名为 g++、c++ 或 CC。如果您使用的是其他编译器,则需要设置一个或多个以下环境变量
|
变量 |
描述 |
|---|---|
|
CXX |
编译器的名称,例如 |
|
CXXFLAGS |
要使用的编译器标志,例如 |
|
LDFLAGS |
要使用的链接器标志,例如 |
|
LIBS |
要链接的任何库,例如 |
例如,要使用 HP aCC 运行 configure 脚本,您可以使用类似以下的命令:
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
无论您如何运行 configure 脚本,完成后,您会在 <boost-root>/libs/config/ 目录中找到一个新的头文件 - user.hpp。 请注意,configure 默认不会将此头文件安装到您的 boost include 路径中。此头文件包含 configure 脚本生成的所有选项,以及一个包含默认版本 <boost/config/user.hpp> 中用户可设置选项的头文件部分(位于 <boost-root>/boost/config/ 下)。您可以通过以下两种方式使用此头文件:
/boost/config/,以替换 boost 提供的默认 user.hpp。此选项只允许一种 configure 生成的设置;Boost 开发人员应避免此选项,因为它存在意外将 configure 修改的 <boost/config/user.hpp> 提交到 svn 存储库的危险(这不会受到欢迎!)。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> 和 configure 生成的 user.hpp 头文件的开头。您可以在命令行上定义它们,或通过编辑 <boost/config/user.hpp> 来定义它们,它们在下表中列出:
|
宏 |
描述 |
|---|---|
|
|
当定义此宏时,它应该指向用户配置文件名,该文件将在任何 Boost 配置文件之前包含。未定义时,默认为 |
|
|
当定义此宏时,它应该指向要使用的编译器配置文件名。定义此宏会排除编译器选择逻辑,并消除对包含该逻辑的头文件的依赖。例如,如果您使用的是 gcc,那么您可以将 BOOST_COMPILER_CONFIG 定义为 |
|
|
当定义此宏时,它应该指向要使用的标准库配置文件名。定义此宏会排除标准库选择逻辑,并消除对包含该逻辑的头文件的依赖。例如,如果您使用的是 STLport,那么您可以将 |
|
|
当定义此宏时,它应该指向要使用的平台配置文件名。定义此宏会排除平台选择逻辑,并消除对包含该逻辑的头文件的依赖。例如,如果您在 Linux 上编译,那么您可以将 |
|
|
当定义此宏时,不会选择或包含任何编译器配置文件。当编译器完全符合标准,或者用户头文件(参见 |
|
|
当定义此宏时,不会选择或包含任何标准库配置文件。当标准库完全符合标准,或者用户头文件(参见 |
|
|
当定义此宏时,不会选择或包含任何平台配置文件。当平台完全符合标准(且没有有用的额外功能),或者用户头文件(参见 |
|
|
等同于定义所有 |
|
|
对于比已知最新版本更新的编译器版本,默认行为是假设它们具有与已知最新版本相同的缺陷。通过设置此宏定义,那么比已知最新版本更新的编译器版本被假定为完全符合标准。这可能最适用于 Boost 开发人员或测试人员,以及那些想使用 Boost 测试 Beta 编译器版本的人。 |
|
|
当设置此标志时,如果配置发现任何未知项,它将停止并显示 #error 而不是继续。Boost 回归测试人员应设置此宏定义,任何想要快速检查其平台是否支持 Boost 的人也应该设置。 |
|
|
当定义此宏时,将禁用线程支持,即使编译器在其当前翻译模式下支持多线程。 |
|
|
当定义此宏时,将禁用 Win32 特定 API 的使用,即使这些 API 可用。除非设置了 |
|
|
阻止 boost 头文件包含任何通常控制结构打包和对齐等功能的 prefix/suffix 头文件。 |
|
|
一个前缀头文件,用于替换 Boost.config 通常选择的任何内容,任何替换都应根据需要设置结构打包和对齐选项。 |
|
|
一个后缀头文件,用于替换 Boost.config 通常选择的任何内容,任何替换都应撤销前缀头文件的影响。 |
|
|
强制所有具有独立源代码的库在 Microsoft Windows 上链接为 DLL 而不是静态库(此宏用于开启 |
|
|
强制库“whatever”在 Microsoft Windows 上链接为 DLL 而不是静态库:用您想动态链接的库的名称替换宏名称中的 WHATEVER 部分;例如,使用 |
|
|
告诉配置系统不要自动选择要链接的库。通常,如果编译器支持 #pragma lib,那么只需包含该库的头文件之一,就可以自动选择并链接正确的库构建变体。此宏关闭该功能。 |
|
|
告诉配置系统不要自动选择要链接的库“whatever”的库。用库的名称替换宏名称中的 WHATEVER;例如 |
|
|
导致自动链接代码输出诊断消息,指示所选链接库的名称。 |
|
|
如果您使用 |
|
|
覆盖链接库名称中 toolset 部分的名称;请注意,如果已定义,则必须将其定义为带引号的字符串字面量,例如“abc”。 |
通过在编译器命令行上设置各种宏或通过编辑 <boost/config/user.hpp>,可以以多种方式优化 Boost 配置设置。
Boost 的配置结构如下:首先包含用户配置(如果未定义 BOOST_USER_CONFIG,则默认为 <boost/config/user.hpp>)。这会设置任何用户定义的策略,并为用户配置提供了影响后续操作的机会。
接下来包括编译器、标准库和平台配置文件。这些是通过宏(BOOST_COMPILER_CONFIG 等,参见用户可设置宏)包含的,如果相应的宏未定义,则会包含一个单独的头文件来检测正在使用的编译器/标准库/平台并进行设置。如果设置了相应的 BOOST_NO_XXX 宏(例如 BOOST_NO_COMPILER_CONFIG 来禁用包含任何编译器配置文件 - 参见用户可设置宏),则可以告知配置忽略这些头文件。
最后,Boost 配置头文件包含 <boost/config/detail/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 尚未支持的 Beta 编译器版本。
假设您正在使用一个完全符合标准的编译器来使用 Boost;您不关心旧版本编译器可能存在的错误,因为您知道您当前的版本不需要设置任何配置宏。在这种情况下,您可以在命令行上或在 <boost/config/user.hpp> 中定义 BOOST_NO_COMPILER_CONFIG,完全跳过编译器配置文件(实际上,您会跳过两个头文件:一个用于确定编译器是什么,另一个用于为编译器配置 Boost)。这有两个后果:一是需要编译的代码更少,二是消除了对两个 Boost 头文件的依赖。
如果您在类 Unix 平台上工作,那么您可以使用 configure 脚本根据您当前的编译器设置生成一个“冻结”配置 - 参见使用 configure 脚本以获取更多详细信息。
Boost 配置库在 <boost-root>/boost/config/test/ 子目录下提供了一整套回归测试程序。
|
文件 |
描述 |
|---|---|
|
|
打印出关于您的编译器/标准库/平台设置以及您当前 Boost 配置的详细描述。此程序提供的信息对于设置 Boost 配置文件非常有用。如果您报告 Boost 为您的编译器/库/平台配置不正确,请在报告所需的更改时附上此程序的输出。 |
|
|
一个单体的测试程序,包含大多数单独的测试用例。这提供了一个快速检查,以查看 Boost 是否为您的编译器/库/平台正确配置。 |
|
|
测试您的标准库的 |
|
|
单个编译器缺陷测试文件。这些文件中的每一个都应该可以编译;如果其中一个不能编译,那么就需要定义相应的 |
|
|
单个编译器缺陷测试文件。这些文件中的每一个都不应该可以编译;如果其中一个可以编译,那么就意味着在不需要的时候定义了相应的 |
|
|
单个功能测试文件。如果这些文件中的一个可以编译,那么就意味着在不应该定义的情况下定义了相应的 |
|
|
单个功能测试文件。如果这些文件中的一个不能编译,那么就意味着在应该定义的情况下没有定义相应的 |
尽管您可以将配置回归测试作为单个测试文件运行,但由于数量众多,这里有两个快捷方式可以帮助您。
或者,您可以这样运行 configure 脚本:
./configure --enable-test
在这种情况下,脚本将测试当前配置,而不是从头开始创建新配置。
如果您要报告新平台/库/编译器这些测试的结果,请附上完整的编译器输出日志、来自 config_info.cpp 的输出以及通过/失败的测试结果。