+
+
+ 
+ Previous topic
+Building individual libraries with cmake
+Next topic
+Adding a Compiled Library to CMake
+Building individual libraries with cmake
+Adding a Compiled Library to CMake
+This page describes how to introduce a new Boost library project into +the CMake-based build system. Any Boost library that provides a +library binary (e.g., boost_signals.dll) or has regression tests +(hopefully, every Boost library!) will need to be part of the build +system.
+To introduce a new library, which resides in the subdirectory +libs/libname, follow these steps:
+Create a new file libs/libname/CMakeLists.txt with your +favorite text editor. This file will contain an invocation of the +boost_library_project, which +identifies each Boost library to the build system. The invocation +of the boost_library_project will look like this:
+boost_library_project(
+ Libname
+ SRCDIRS src
+ TESTDIRS test
+ EXAMPLEDIRS test
+ )
+where Libname is the properly-capitalization library name, +e.g., Signals or Smart_ptr. The SRCDIRS src line should +only be present if your Boost library actually needs to compile a +library binary; header-only libraries can skip this step. The +TESTDIRS test line indicates that the subdirectory test +contains regression tests for your library. Every Boost library +should have these.
+Re-run CMake (see Quickstart) to reconfigure the source +tree, causing CMake to find the new Boost library. CMake can be +re-run either from the command line (by invoking cmake +/path/to/boost or ccmake /path/to/boost) or, on Windows, +using the CMake GUI. Once you have reconfigured and generated new +makefiles or project files, CMake knows about your library.
+If your library has compiled sources (i.e., it is not a header-only +library), follow the instructions on Adding a Compiled Library to CMake to +get CMake building and installing your library.
+If your library has regression tests (it does regression tests, +right?), follow the instructions on Adding Regression Tests +to get CMake to build and run regression tests for your library.
+This page describes how to add a new, compiled library to the +CMake-based build system. If your library is a “header-only” library, +and does not require separate compilation of object files into a +library binary, you can safely skip this step. Before adding compiled +libraries to CMake, make sure you have already followed the directions +for boost_library_project, so that the CMake system recognizes your +Boost library.
+We will assume that your library resides in the subdirectory +libs/libname, and that we want to create the compiled library +boost_libname. We will also assume that the sources for this +library reside in the subdirectory libs/libname/src. The source +directory should be listed via SRCDIRS in the use of the +boost_library_project macro, as described in the previous +section. Follow these steps to add this new +library into Boost’s build system. If your library has multiple source +directories listed after SRCDIRS, follow these steps for each one.
+Create a new file libs/libname/src/CMakeLists.txt with your +favorite text editor. This file will contain build rules for your +compiled library. In this file, we will create one or more +invocations of the boost_add_library macro, which adds a +compiled Boost library to the CMake system. This macro provides the +name of the library, the source files from which the library will +be built, and any specific compiler and linker options needed to +help build the library. Let’s start by adding a simple library with +a few source files:
+boost_add_library(libname
+ mysrc1.cpp mysrc2.cpp
+ )
+This invocation will build several variants of the +boost_libname library from the source files mysrc1.cpp and +mysrc2.cpp. For example, it will build both static and shared +library, single- and multi-threaded, debug and release, etc. This +invocation also handles the installation of these libraries.
+For simple libraries, that’s it! Rebuilding via CMake (e.g., +running make or reloading and rebuilding the Boost project in +your IDE) will build the new library, including several different +variants for different compilation options. Your Boost library will +also be included when the user installs Boost or builds a binary +package of Boost. Within the CMake configuration, you will also see +an option BUILD_LIBNAME, which allows the user to decide +whether or not to build this Boost library.
+Many libraries will need specific compilation options when +building, need to link against other libraries (Boost or +otherwise), or rely on certain features of the compilation process +to proceed. Follow the instructions in the remaining part of this +page to address these library-specific needs.
+Many libraries require certain compilation flags when we are building +the library binaries themselves (rather than when the library headers +are included by the user). For example, we want to define the macro +BUILDING_BOOST_LIBNAME when building the library. We can do so by +passing the COMPILE_FLAGS option to boost_add_library:
+boost_add_library(libname
+ mysrc1.cpp mysrc2.cpp
+ COMPILE_FLAGS "-DBUILDING_BOOST_LIBNAME=1"
+ )
+Now when CMake builds the library, it will pass the flag +-DBUILDING_BOOST_LIBNAME=1 to the compiler.
+On Windows, shared libraries are built very differently from static +libraries. In particular, when building a shared library, one needs to +be sure to export the right symbols from the DLL using +dllexport. When users use the shared library, these symbols will be +imported (via dllimport). The typical way to handle this is to +define a macro (say, BOOST_LIBNAME_DYN_LINK) when building the +shared library. This macro instructs the library headers to +dllexport everything that needs to be exported. We can do this with +variant-specific compile flags, e.g.,
+boost_add_library(libname
+ mysrc1.cpp mysrc2.cpp
+ COMPILE_FLAGS "-DBUILDING_BOOST_LIBNAME=1"
+ SHARED_COMPILE_FLAGS "-DBOOST_LIBNAME_DYN_LINK=1"
+ )
+When building a shared library, the SHARED_COMPILE_FLAGS options +will be combined with the COMPILE_FLAGS options. When building a +static library, the SHARED_COMPILE_FLAGS options will be +ignored. There are other options that can be specified per-feature, +such as LINK_FLAGS and LINK_LIBS; refer to the +boost_add_library reference for more +information.
+Some Boost libraries depends on other Boost libraries. For example, +perhaps our library uses the Boost.Filesystem library under the +hood. We can use the DEPENDS feature of the +boost_add_library to state which libraries our library +depends on. In this example, we’ll link against boost_filesystem:
+boost_add_library(libname
+ mysrc1.cpp mysrc2.cpp
+ COMPILE_FLAGS "-DBUILDING_BOOST_LIBNAME=1"
+ SHARED_COMPILE_FLAGS "-DBOOST_LIBNAME_DYN_LINK=1"
+ DEPENDS boost_filesystem
+ )
+Now, each variant of the boost_libname library will link against +the appropriate boost_filesystem library variant. Whenever +boost_filesystem changes, our library will be relinked +appropriately.
+Sometimes, Boost libraries need to link against other libraries +supplied by the system. The primary challenge in linking against these +libraries is finding those libraries, and their associated headers, +on the system. If the library is found, we usually want to pass some +extra compilation flags to our library and add in additional +sources. Otherwise, we just skip these extra sources.
+CMake already contains modules that search for many common system +libraries and tools; search the +[http://www.cmake.org/HTML/Documentation.html CMake Documentation] for +existing modules that do what you need. For example, say we want to +link against the system’s PNG (portable network graphics) library. +We can use the supplied FindPNG module by adding the following +early in our CMakeLists.txt file:
+include(FindPNG)
+Documentation for CMake modules is typically found in the module file +itself. Look into the Modules subdirectory of your CMake +installation, either in Program Files\CMake (on Windows) or +/usr/share/cmake-version (on Unix variants) to find the module of +the same name. The module will typically set a variable that indicates +whether the library was found. For the FindPNG module, this variable +is called PNG_FOUND. We can use this variable to optionally add +sources to a variable EXTRA_SOURCES:
+include(FindPNG)
+set(EXTRA_SOURCES)
+if (PNG_FOUND)
+ list(APPEND EXTRA_SOURCES png.cpp)
+endif (PNG_FOUND)
+CMake modules also typically define macros specifying the include +directories needed for the library, any compile-time definitions +required to use the library, and linking information for the library +binary. For the FindPNG module, these variables are called +PNG_INCLUDE_DIR, PNG_DEFINITIONS and PNG_LIBRARY, respectively.
+The include directory should be added via the CMake +include_directories macro, e.g.,
+include_directories(${PNG_INCLUDE_DIR})
+The PNG_DEFINITIONS value should be added to the COMPILE_FLAGS +and the PNG_LIBRARIES value to the LINK_LIBS option to the +boost_add_library. Using these features together, we can +search for the PNG library on the system and optionally include +PNG support into our library:
+include(FindPNG)
+set(EXTRA_SOURCES)
+if (PNG_FOUND)
+ include_directories(${PNG_PNG_INCLUDE_DIR})
+ list(APPEND EXTRA_SOURCES png.cpp)
+endif (PNG_FOUND)
+
+boost_add_library(libname
+ mysrc1.cpp mysrc2.cpp
+ ${EXTRA_SOURCES}
+ COMPILE_FLAGS "-DBUILDING_BOOST_LIBNAME=1 ${PNG_DEFINITIONS}"
+ LINK_LIBS "${PNG_LIBRARIES}"
+ SHARED_COMPILE_FLAGS "-DBOOST_LIBNAME_DYN_LINK=1"
+ DEPENDS boost_filesystem
+ )
+If CMake does not provide a module to search for the library you need, +don’t worry! You can write your own module relatively easily, +following the examples from the CMake Modules directory or some of +the Boost-specific examples, such as +http://svn.boost.org/svn/boost/branches/release/tools/build/CMake/FindICU.cmake +For a real-life example of finding system libraries and using that +information to add optional, extra capabilities to a Boost library, +check out the build rules for the Boost.IOStreams library at +http://svn.boost.org/svn/boost/branches/release/libs/iostreams/src/CMakeLists.txt
+The Boost build system defines many different Build Variants and Features, which +describe specific properties of certain builds. For example, the +SHARED feature indicates that we are building a shared library, +while the MULTI_THREADED feature indicates that we are building a +multi-threaded library. A specific set of features is called a +````variant````, e.g., RELEASE and MULTI_THREADED and +SHARED. By default, the CMake-based build system builds several +different variants of each Boost library.
+Since some features conflict with certain libraries (a threading +library cannot be SINGLE_THREADED!), one can pass additional flags +to boost_add_library stating which features should the library +cannot be built with. For example, say that our library cannot be +built as a multi-threaded library, because it uses thread-unsafe +routines from the underlying C library. To disable multi-threaded +variants of the library, pass the option NOT_MULTI_THREADED:
+boost_add_library(libname
+ mysrc1.cpp mysrc2.cpp
+ COMPILE_FLAGS "-DBUILDING_BOOST_LIBNAME=1"
+ SHARED_COMPILE_FLAGS "-DBOOST_LIBNAME_DYN_LINK=1"
+ DEPENDS boost_filesystem
+ NOT_MULTI_THREADED
+ )
+This page describes how to add regression tests for a Boost library in +the CMake-based build system. Before adding regression tests, make +sure you have already followed the directions for +boost_library_project , so that the CMake system +recognizes your Boost library project, and (if necessary) +Adding a Compiled Library to CMake. We also assume that you have already +configured your build tree for regression testing of your library, by +adding your library project’s name to the BUILD_TESTS option +described in the section Testing.
+In this page, we will assume that your library resides in the +subdirectory libs/libname, and that tests for this library are +stored in libs/libname/test. The test directory should be listed +via TESTDIRS in the call of +boost_library_project. Follow these steps to add this new +library into Boost’s build system. If your library has multiple +testing directories listed after TESTDIRS, follow these steps for +each one.
+Create a new file libs/libname/test/CMakeLists.txt file with +your favorite text editor. This file will contain instructions for +building and running each of the regression tests for your library.
+If your regression test depends on any other part of boost then +you will need to inform the build system of such with the +following line:
+boost_additional_test_dependencies(libname BOOST_DEPENDS test fusion)
+where ‘libname’ is the name of your library that you are testing.
+For each test that only needs to be compiled (but not executed), +add a compile or compile_fail test using the +boost_test_compile or boost_test_compile_fail +macros, respectively. The most basic usage of these macros +provides only the test name, e.g.,
+boost_test_compile(compile_test)
+boost_test_compile_fail(compile_fail_test)
+This code will create two regression tests. The first, +compile_test, will try to compile the source file +compile_test.cpp in the current source directory. If the +compile is successful, the regression test passes. If the compile +fails, the regression test fails. The second regression test works +the opposite way: it will try to compile +compile_fail_test.cpp: if the compilation is successful, the +regression test fails. When you run the regression tests (e.g., by +calling ctest from the build directory), the regression tests +will execute and produce output like the following:
+Running tests...
+Start processing tests
+Test project /Users/dgregor/Projects/boost-darwin
+ 1/ 2 Testing libname::compile_test Passed
+ 2/ 2 Testing libname::compile_fail_test ***Failed - supposed to fail
+
+100% tests passed, 0 tests failed out of 2
+For any tests that need to be built and executed, use the +boost_test_run or boost_test_run_fail macros. Both +tests will build, link and execute a regression test. The +boost_test_run macro expects that executable to return an +exit code of zero, while the boost_test_run_fail macro +expects that executable to return a non-zero exit code. For +example, we might build a simple test simple_test from the +source file simple_test.cpp:
+boost_test_run(simple_test)
+Often, we’ll want to link against our own Boost library, which we +do using the DEPENDS argument to boost_test_run:
+boost_test_run(big_test big_test1.cpp big_test2.cpp
+ DEPENDS boost_libname-static
+ )
+Here, we have created a test big_test, built from the source +files big_test1.cpp and big_test2.cpp, which will link +against the static library for boost_libname. We could create +a similar test that links against the shared library for +boost_libname, passing along compilation flags specific to the +shared library:
+boost_test_run(big_test_dll big_test1.cpp big_test2.cpp
+ DEPENDS boost_libname-shared
+ COMPILE_FLAGS "-DBOOST_LIBNAME_DYN_LINK=1"
+ )
+Some tests require command-line arguments. For example, say we +want to pass -loop 1000 to a randomized test. We can do so +using the ARGS argument to boost_test_run (or +boost_test_run_fail):
+boost_test_run(random_test ARGS "-loop" "1000" DEPENDS boost_libname-static)
+Once you have finished describing your regression tests to the +CMake system, you’re done! Your library will now build, test, and +install with CMake and this behavior should be portable across +many different platforms.
+Included in the standard cmake distribution are the Windows CMake +gui and the unix ccmake curses interface, which allow one to +configure various aspects of the cmake build. On Microsoft Windows +run the CMake configuration program from the Start menu.
+Having done the initial configuration step as in Quickstart, +on unix run:
+make edit_cache
+in the binary directory. On windows just run the cmake gui and choose +the binary dir from the pulldown menu. You will be presented with a list of editable build options something +like this:
+BOOST_PLATFORM linux
+BUILD_BCP ON
+BUILD_BOOST_WSERIALIZATION ON
+BUILD_EXAMPLES NONE
+BUILD_INSPECT ON
+BUILD_TESTS NONE
+CMAKE_BUILD_TYPE Release
+CMAKE_INSTALL_PREFIX /usr/local
+DART_TESTING_TIMEOUT 15
+DEBUG_COMPILE_FLAGS -g
+DOCBOOK_AUTOCONFIG OFF
+DOCBOOK_DTD_DIR DOCBOOK_DTD_DIR-NOTFOUND
+DOCBOOK_XSL_DIR DOCBOOK_XSL_DIR-NOTFOUND
+ENABLE_DEBUG ON
+ENABLE_MULTI_THREADED ON
+ENABLE_RELEASE ON
+ENABLE_SHARED ON
+ENABLE_SINGLE_THREADED OFF
+ENABLE_STATIC ON
+RELEASE_COMPILE_FLAGS -O3 -DNDEBUG
+UNZIP /usr/bin/unzip
+WINMANGLE_LIBNAMES OFF
+XSLTPROC /usr/bin/xsltproc
+XSLTPROC_FLAGS --xinclude
+On windows, the configurables will be right in the middle of the gui; +can’t miss ‘em. Note the [t] key to toggle ‘advanced mode’ which +will show more options (on windows this is a selection box that says +Simple View by default, pull it down to see Advanced and Grouped +views).
+Use the arrow keys to select particular options. Press c (for +(c)onfigure) to perform the preliminary configuration of the CMake +build system when you are done. When the options you have selected +have stabilized, CMake will give you the (g)enerate option. If you do +not see this option, press c again to reconfigure. Try the +t key to see more options. When you’re done press g to +generate makefiles and exit.
+See Build Variants and Features for information about the feature-specific options +(ie ENABLE_whatever listed above.)
+The same information is stored in a file CMakeCache.txt located in +the build directory. For this reason, after you’ve done the initial +configuration of a build directory you can invoke ccmake like this:
+ccmake <path-to-build>
+or have the makefiles do it for you:
+make edit_cache
+The CMakeCache.txt file is hand-editable, though this is usually not +as convenient as the cmake-supplied configuration tools mentioned +above. An excerpt of this file:
+//
+// Enable/Disable color output during build.
+//
+CMAKE_COLOR_MAKEFILE:BOOL=ON
+
+//
+// Mangle lib names for windows, e.g., boost_filesystem-gcc41-1_34
+//
+WINMANGLE_LIBNAMES:BOOL=ON
+On unix, (?windows too?) the generated makefiles will detect if this +file has been edited and will automatically rerun the makefile +generation phase. If you should need to trigger this regeneration +manually you may execute
+make rebuild_cache
+Deleting the cache
+You may find yourself wanting to start from scratch, for instance if +you want to switch from using Visual Studio to using NMake. To do +this, delete the cache file. On windows, there is a Delete +Cache option in the CMake gui’s File menu. On unix you can simply +rm CMakeCache.txt.
+This variable is set by cmake and corresponds to the toplevel of your +build/ directory.
++++
+- Mac OS X users: to build universal binaries, set this to
+- ppc;i386.
+
This option controls whether libraries will be built with mangled-in +compiler name/version and boost version. For example, with +BUILD_VERSIONED set to OFF, the signals library looks like +this:
+% ls lib/*signals*
+lib/libboost_signals-mt-d.a lib/libboost_signals-mt.a
+lib/libboost_signals-mt-d.so* lib/libboost_signals-mt.so*
+But with it on, (on a gcc 4.3 linux box):
+% ls lib/*signal*
+lib/libboost_signals-gcc43-mt-1_40.a
+lib/libboost_signals-gcc43-mt-d-1_40.a
+lib/libboost_signals-gcc43-mt-1_40.so*
+lib/libboost_signals-gcc43-mt-d-1_40.so*
+Historically this mangling has been convenient for windows users and a +bane to unix users, thus winmangle_libnames.
+ +This is a semicolon-separated list of projects to be built, or +"ALL" (the default) for all projects, or "NONE". Projects not +appearing in this list (if list not "ALL") are ignored; no targets in +this project will appear. Example:
+BUILD_PROJECTS=thread;python
+See also the boost_library_project macro.
+Note
+If you specify a project with link time dependencies on other +projects, e.g. filesystem, (which depends on system) and +omit the dependencies, you will get an error from cmake something +like this:
+CMake Error at tools/build/CMake/BoostCore.cmake:736 (get_property):
+ get_property could not find TARGET boost_system-mt-shared. Perhaps it has
+ not yet been created.
+Call Stack (most recent call first):
+ tools/build/CMake/BoostCore.cmake:1170 (boost_library_variant)
+ libs/filesystem/src/CMakeLists.txt:7 (boost_add_library)
+This is a semicolon-separated list of projects whose examples should +be built, e.g.:
+BUILD_EXAMPLES="iostreams;accumulators"
+Warning
+If you pass this on the commandline in a unix shell, +don’t forget to quote the list of arguments or escape the +semicolons...
+Per-library examples are specified with the EXAMPLEDIRS +argument to the boost_library_project macro.
+Note:
+A project’s examples will only be built if the project appears in +both BUILD_PROJECTS and BUILD_EXAMPLES. I.e., the +BUILD_PROJECTS filter is applied first, and the BUILD_EXAMPLES +filter has no ability to reverse the result.
+Similar to BUILD_EXAMPLES and BUILD_PROJECTS above, this is a +semicolon-separated list of tools (in subdirectory +$BOOST_ROOT/tools/) that should be built, e.g.:
+BUILD_TOOLS=quickbook;wave
+"ALL" will build all tools, "NONE" will build none. Note that +the values here are lowercase (only subdirectories of tools/ +matching one of the strings in the list will be traversed by cmake).
++Displays full build commands during build. Good for debugging. +This option will generate permanently verbose makefiles; it is +generally easier to invoke make with the option VERBOSE=1 +instead (this has the same effect, but is not persistent).+
++Sets the compiler. If you have a nonstandard compiler and no +default compiler, you may have to pass the value of this option on +the commandline, for example:
++cmake ../src -DCMAKE_CXX_COMPILER=gcc-4.4+On windows you can set this in the gui, but you will probably prefer +to have cmake generate a set of nmake or project files by choosing +an appropriate generator.
+
Enables the setting of SOVERSION in built libraries. If +this is on:
+% ls -l libboost_thread*.so*
+lrwxrwxrwx 1 troy troy 30 Oct 29 18:37 libboost_thread-mt-d.so -> libboost_thread-mt-d.so.1.41.0*
+-rwxr-xr-x 1 troy troy 571361 Oct 29 18:37 libboost_thread-mt-d.so.1.41.0*
+lrwxrwxrwx 1 troy troy 28 Oct 29 18:37 libboost_thread-mt.so -> libboost_thread-mt.so.1.41.0*
+-rwxr-xr-x 1 troy troy 114963 Oct 29 18:37 libboost_thread-mt.so.1.41.0*
+
+% readelf -a libboost_thread-mt.so | grep SONAME
+ 0x000000000000000e (SONAME) Library soname: [libboost_thread-mt.so.1.41.0]
+and if off:
+% ls -l lib/*signals*
+-rwxr-xr-x 1 troy troy 835522 Oct 29 15:10 lib/libboost_signals-mt-d.so*
+-rwxr-xr-x 1 troy troy 121886 Oct 29 15:10 lib/libboost_signals-mt.so*
+(Unix only, ON by default)
+This setting also determines whether libraries are installed +with/without soversions. See also INSTALL_VERSIONED.
+CMake can easily build binary installers for a variety of +platforms. On Windows and Mac OS X, CMake builds graphical +installation programs. For other Unix operating systems, CMake +currently builds tarballs and self-installing shell scripts. This +CMake functionality, provided by the +CPack program +that is part of CMake, is used to create all of CMake’s binary +installers. We use CPack to build binary installers for Boost. To +build a binary installer for Boost, follow these steps:
+The output of the packaging process will be one or more binary +packages of the form Boost-version-platform.*extension*. The +type of package will differ from one platform to another:
+Windows installer:
+
+Mac installer:
+
+Tricks for Building against Boost with CMake
+Different compilation and linking flags affect how source code and +libraries are compiled. Boost’s build system abstracts some of these +properties into specific features of the build, which indicate (at +a high level) what options are being used, e.g., multi-threaded, +release-mode, shared libraries, etc. Each feature brings with it +certain compilation options (which vary from one compiler to the next) +that need to be used when building that variant. For example, on Unix +systems, one often must link against the pthread library for +multi-threaded programs and libraries, which requires the addition of +the -lpthread flag to the link line. The ‘’features’’ feature of the +build system encapsulates this knowledge.
+A library built with a given set of features is called a library +variant. For example, we could have a multi-threaded release variant +of a shared library, which would be built with all of the options +needed to support multi-threading, optimization, elimination of +debugging symbols, and for building a shared library. Each variant of +a library is given a unique name based on the features in that +variant, so that one can readily identify the library, for example, +libboost_signals-gcc40-mt-d.so is the multi-threaded, debug version +of the shared library for Boost.Signals on a typical Linux system. The +Boost Getting Started guide +describes the library naming conventions used for the variants.
+The configuration and build of the library for each feature is +(dis|en)abled with a boolean option ENABLE_feature, which set +in CMakeCache.txt. The available features are:
+Libraries have their features mangled in to distinguish the variants +from one another. CMake’s symbolic target names correspond:
+| Feature | +Target Name | +Library Name Component | +
|---|---|---|
| shared | +-shared | +(none) | +
| static | +-static | +(none) | +
| multithreaded | +-mt | +-mt | +
| release | +(none) | +(none) | +
| debug | +-debug | +-d | +
| pydebug | +-pydebug | +-yd | +
The make target help will show the available options:
+``make help`` shows a list::
+
+% make help | grep signals
+... boost_signals
+... boost_signals-mt-shared
+... boost_signals-mt-shared-debug
+... boost_signals-mt-static
+... boost_signals-mt-static-debug
+... boost_signals-shared
+... boost_signals-shared-debug
+... boost_signals-static
+... boost_signals-static-debug
+And you can see the correspondence to the libraries on disk:
+% ls lib/libboost_signals*
+lib/libboost_signals-d.a lib/libboost_signals-mt.a
+lib/libboost_signals-d.so lib/libboost_signals-mt.so
+lib/libboost_signals-mt-d.a lib/libboost_signals.a
+lib/libboost_signals-mt-d.so lib/libboost_signals.so
+(Note: on most unix you will see more than this, as some of them +contain version numbers and are symbolic links to one another).
+You can globally (en|dis)able the build of these various features +through the following cmake variables:
++The STATIC feature identifies static builds of libraries, i.e., a +.lib (library) file on Microsoft Windows or a .a (archive) file +on Unix systems.+
+The DEBUG feature identifies builds of libraries that retain +complete debugging information and prohibit optimization, making +these builds far easier to use for debugging programs.+
+The RELEASE feature identifies builds of libraries that use full +optimization and eliminate extraneous information such as debug +symbols, resulting in builds of libraries that are typically much +smaller than (and execute faster than) their debug library +counterparts.+
+The SINGLE_THREADED feature identifies builds of libraries that +assume that the program using them is single-threaded. These +libraries typically avoid costly atomic operations or locks, and +make use of no multi-threaded features.+
+The MULTI_THREADED feature identifies builds of libraries that +assume that the program using them is multi-threaded. These +libraries may introduce additional code (relative to their +single-threaded variants) that improves the behavior of the +library in a multi-threade context, often at the cost of +single-thread performance.+
+The STATIC_RUNTIME feature identifies builds that link against +the C and C++ run-time libraries statically, which directly +includes the code from those run-time libraries into the Boost +library or executable.+
+The DYNAMIC_RUNTIME feature identifies builds that link against +the dynamic C and C++ run-time libraries.+
For each feature above, the Boost build system defines three variables +used to provide compilation flags, linking flags, and extra libraries +to link against when using that feature. These flags are automatically +added to the build commands for variants using that feature. The +particular flags and libraries are described by the following global +variables:
++A string containing extra flags that will be added to the compile +line, including macro definitions and compiler-specific flags +needed to enable this particular feature.+
+A string containing extra flags that will be added to the +beginning of the link line. Note that these flags should ‘’‘not’‘’ +contain extra libraries that one needs to link against. Those +should go into feature_LINK_LIBS.+
+A CMake list containing the names of additional libraries that +will be linked into libraries and executables that require this +feature. The elements in this list should name the library (e.g., +pthread) rather than providing the link command itself (e.g., +-lpthread), so that linking will be more portable.+
Each of these variables can be expanded for any feature, e.g., +MULTI_THREADED_LINK_LIBS contains libraries that multi-threaded +variants should link against.
+All of the flags provided for each feature are typically detected by +the Boost CMake configuration module in +tools/build/CMake/BoostConfig.cmake.
+Note
+These are global per-feature flags, ie +RELEASE_COMPILE_FLAGS defines flags used for the compilation +of all .cpp files that go into release libraries. See +boost_add_library for per-feature flags that apply only to +individual libraries.
+By default, Boost’s build system will build every permutation of +libraries in the feature space
++(STATIC or SHARED) x (DEBUG or RELEASE) x +(SINGLE_THREADED or MULTI_THREADED)+
resulting in 8 different copies of each library, modulo certain cases +where variants are disabled [1]. On Windows, where +the distinction between static and dynamic run-time libraries is very +important, the default build also creates permutations with +(STATIC_RUNTIME or DYNAMIC_RUNTIME). Certain non-sensical +combinations of libraries will automatically be eliminated, e.g., it +does not generally make sense to create a shared library that links +against the static C and C++ run-time libraries. However, this still +means that the default build creates between 8 and 12 different +variants of each Boost library.
+Users who only need a few variants of each library can change which +variants of Boost libraries are build by default using various +configuration options. For each feature, CMake’s configuration will +contain an option ENABLE_feature. When the feature is ON, the build +system will produce variants with that feature. When the feature is +OFF, the build system will suppress variants with that feature. For +example, toggling ENABLE_DEBUG to OFF will inhibit the creation of +the debug variants, drastically improving overall build times.
+Footnotes
+| [1] | For instance, the SINGLE_THREADED variant +of the boost_thread project is disabled. |
The only differences below should be in the build system... but there +should be a lot of them. :)
+% git diff --stat=100,90 Boost_1_41_0
+ .gitignore | 8 +
+ CMakeLists.txt | 413 ++-
+ CTestConfig.cmake | 21 +
+ doc/CMakeLists.txt | 9 +
+ doc/src/CMakeLists.txt | 19 +
+ libs/CMakeLists.txt | 99 +
+ libs/accumulators/CMakeLists.txt | 21 +
+ libs/accumulators/doc/CMakeLists.txt | 8 +
+ libs/accumulators/example/CMakeLists.txt | 8 +
+ libs/accumulators/module.cmake | 1 +
+ libs/accumulators/test/CMakeLists.txt | 82 +
+ libs/algorithm/CMakeLists.txt | 22 +
+ libs/algorithm/minmax/test/CMakeLists.txt | 10 +
+ libs/algorithm/module.cmake | 4 +
+ libs/algorithm/string/test/CMakeLists.txt | 18 +
+ libs/any/CMakeLists.txt | 27 +
+ libs/any/module.cmake | 1 +
+ libs/any/test/CMakeLists.txt | 11 +
+ libs/array/CMakeLists.txt | 27 +
+ libs/array/module.cmake | 1 +
+ libs/array/test/CMakeLists.txt | 14 +
+ libs/asio/CMakeLists.txt | 28 +
+ libs/asio/module.cmake | 3 +
+ libs/asio/test/CMakeLists.txt | 127 +
+ libs/asio/test/ip/CMakeLists.txt | 32 +
+ libs/asio/test/local/CMakeLists.txt | 16 +
+ libs/asio/test/posix/CMakeLists.txt | 17 +
+ libs/asio/test/ssl/CMakeLists.txt | 78 +
+ libs/assign/CMakeLists.txt | 28 +
+ libs/assign/module.cmake | 1 +
+ libs/assign/test/CMakeLists.txt | 28 +
+ libs/bimap/CMakeLists.txt | 28 +
+ libs/bimap/module.cmake | 1 +
+ libs/bimap/test/CMakeLists.txt | 49 +
+ libs/bind/CMakeLists.txt | 28 +
+ libs/bind/module.cmake | 1 +
+ libs/bind/test/CMakeLists.txt | 47 +
+ libs/circular_buffer/CMakeLists.txt | 29 +
+ libs/circular_buffer/module.cmake | 1 +
+ libs/circular_buffer/test/CMakeLists.txt | 13 +
+ libs/compatibility/CMakeLists.txt | 27 +
+ libs/compatibility/module.cmake | 2 +
+ libs/concept_check/CMakeLists.txt | 29 +
+ libs/concept_check/module.cmake | 1 +
+ libs/concept_check/test/CMakeLists.txt | 14 +
+ libs/config/CMakeLists.txt | 28 +
+ libs/config/test/CMakeLists.txt | 37 +
+ libs/conversion/CMakeLists.txt | 28 +
+ libs/conversion/test/CMakeLists.txt | 20 +
+ libs/crc/CMakeLists.txt | 27 +
+ libs/crc/module.cmake | 1 +
+ libs/crc/test/CMakeLists.txt | 10 +
+ libs/date_time/CMakeLists.txt | 28 +
+ libs/date_time/module.cmake | 1 +
+ libs/date_time/src/CMakeLists.txt | 13 +
+ libs/date_time/test/CMakeLists.txt | 187 +
+ libs/detail/CMakeLists.txt | 27 +
+ libs/detail/module.cmake | 1 +
+ libs/disjoint_sets/CMakeLists.txt | 29 +
+ libs/disjoint_sets/module.cmake | 1 +
+ libs/disjoint_sets/test/CMakeLists.txt | 7 +
+ libs/dynamic_bitset/CMakeLists.txt | 30 +
+ libs/dynamic_bitset/module.cmake | 1 +
+ libs/dynamic_bitset/test/CMakeLists.txt | 13 +
+ libs/exception/CMakeLists.txt | 29 +
+ libs/exception/module.cmake | 1 +
+ libs/exception/test/CMakeLists.txt | 55 +
+ libs/filesystem/CMakeLists.txt | 28 +
+ libs/filesystem/module.cmake | 1 +
+ libs/filesystem/src/CMakeLists.txt | 14 +
+ libs/filesystem/test/CMakeLists.txt | 30 +
+ libs/flyweight/CMakeLists.txt | 18 +
+ libs/flyweight/module.cmake | 1 +
+ libs/flyweight/test/CMakeLists.txt | 53 +
+ libs/foreach/CMakeLists.txt | 27 +
+ libs/foreach/module.cmake | 1 +
+ libs/foreach/test/CMakeLists.txt | 40 +
+ libs/format/CMakeLists.txt | 28 +
+ libs/format/module.cmake | 1 +
+ libs/format/test/CMakeLists.txt | 13 +
+ libs/function/CMakeLists.txt | 28 +
+ libs/function/doc/CMakeLists.txt | 8 +
+ libs/function/module.cmake | 1 +
+ libs/function/test/CMakeLists.txt | 29 +
+ libs/function_types/CMakeLists.txt | 27 +
+ libs/function_types/module.cmake | 1 +
+ libs/function_types/test/CMakeLists.txt | 76 +
+ libs/functional/CMakeLists.txt | 28 +
+ libs/functional/hash/doc/CMakeLists.txt | 8 +
+ libs/functional/hash/examples/CMakeLists.txt | 15 +
+ libs/functional/hash/test/CMakeLists.txt | 58 +
+ libs/functional/module.cmake | 1 +
+ libs/functional/test/CMakeLists.txt | 7 +
+ libs/fusion/CMakeLists.txt | 29 +
+ libs/fusion/module.cmake | 1 +
+ libs/gil/CMakeLists.txt | 28 +
+ libs/gil/module.cmake | 1 +
+ libs/gil/test/CMakeLists.txt | 16 +
+ libs/graph/CMakeLists.txt | 24 +
+ libs/graph/module.cmake | 4 +
+ libs/graph/src/CMakeLists.txt | 38 +
+ libs/graph/test/CMakeLists.txt | 71 +
+ libs/graph_parallel/CMakeLists.txt | 25 +
+ libs/graph_parallel/doc/CMakeLists.txt | 70 +
+ libs/graph_parallel/example/CMakeLists.txt | 59 +
+ libs/graph_parallel/module.cmake | 1 +
+ libs/graph_parallel/src/CMakeLists.txt | 22 +
+ libs/graph_parallel/test/CMakeLists.txt | 121 +
+ libs/integer/CMakeLists.txt | 31 +
+ libs/integer/module.cmake | 1 +
+ libs/integer/test/CMakeLists.txt | 14 +
+ libs/interprocess/CMakeLists.txt | 27 +
+ libs/interprocess/module.cmake | 1 +
+ libs/interprocess/test/CMakeLists.txt | 14 +
+ libs/intrusive/CMakeLists.txt | 28 +
+ libs/intrusive/module.cmake | 1 +
+ libs/io/CMakeLists.txt | 28 +
+ libs/io/module.cmake | 1 +
+ libs/io/test/CMakeLists.txt | 12 +
+ libs/iostreams/CMakeLists.txt | 27 +
+ libs/iostreams/example/CMakeLists.txt | 10 +
+ libs/iostreams/module.cmake | 1 +
+ libs/iostreams/src/CMakeLists.txt | 36 +
+ libs/iostreams/test/CMakeLists.txt | 69 +
+ libs/iterator/CMakeLists.txt | 30 +
+ libs/iterator/module.cmake | 1 +
+ libs/iterator/test/CMakeLists.txt | 39 +
+ libs/lambda/CMakeLists.txt | 27 +
+ libs/lambda/module.cmake | 1 +
+ libs/lambda/test/CMakeLists.txt | 24 +
+ libs/logic/CMakeLists.txt | 27 +
+ libs/logic/module.cmake | 3 +
+ libs/logic/test/CMakeLists.txt | 12 +
+ libs/math/CMakeLists.txt | 28 +
+ libs/math/module.cmake | 1 +
+ libs/math/test/CMakeLists.txt | 33 +
+ libs/mpi/CMakeLists.txt | 31 +
+ libs/mpi/doc/CMakeLists.txt | 36 +
+ libs/mpi/module.cmake | 1 +
+ libs/mpi/src/CMakeLists.txt | 84 +
+ libs/mpi/test/CMakeLists.txt | 77 +
+ libs/mpl/CMakeLists.txt | 28 +
+ libs/mpl/module.cmake | 1 +
+ libs/mpl/test/CMakeLists.txt | 97 +
+ libs/multi_array/CMakeLists.txt | 28 +
+ libs/multi_array/module.cmake | 2 +
+ libs/multi_array/test/CMakeLists.txt | 47 +
+ libs/multi_index/CMakeLists.txt | 29 +
+ libs/multi_index/module.cmake | 1 +
+ libs/multi_index/test/CMakeLists.txt | 34 +
+ libs/numeric/CMakeLists.txt | 27 +
+ libs/numeric/conversion/test/CMakeLists.txt | 17 +
+ libs/numeric/interval/test/CMakeLists.txt | 34 +
+ libs/numeric/module.cmake | 1 +
+ libs/numeric/ublas/test/CMakeLists.txt | 86 +
+ libs/optional/CMakeLists.txt | 28 +
+ libs/optional/module.cmake | 1 +
+ libs/optional/test/CMakeLists.txt | 23 +
+ libs/parameter/CMakeLists.txt | 29 +
+ libs/parameter/module.cmake | 1 +
+ libs/parameter/test/CMakeLists.txt | 31 +
+ libs/pool/CMakeLists.txt | 27 +
+ libs/pool/module.cmake | 1 +
+ libs/pool/test/CMakeLists.txt | 9 +
+ libs/preprocessor/CMakeLists.txt | 28 +
+ libs/preprocessor/module.cmake | 4 +
+ libs/preprocessor/test/CMakeLists.txt | 23 +
+ libs/program_options/CMakeLists.txt | 28 +
+ libs/program_options/module.cmake | 1 +
+ libs/program_options/src/CMakeLists.txt | 11 +
+ libs/program_options/test/CMakeLists.txt | 39 +
+ libs/property_map/CMakeLists.txt | 28 +
+ libs/property_map/module.cmake | 1 +
+ libs/property_map/test/CMakeLists.txt | 11 +
+ libs/proto/CMakeLists.txt | 27 +
+ libs/proto/module.cmake | 2 +
+ libs/proto/test/CMakeLists.txt | 58 +
+ libs/ptr_container/CMakeLists.txt | 27 +
+ libs/ptr_container/module.cmake | 1 +
+ libs/ptr_container/test/CMakeLists.txt | 28 +
+ libs/python/CMakeLists.txt | 21 +
+ libs/python/module.cmake | 3 +
+ libs/python/src/CMakeLists.txt | 70 +
+ libs/python/test/CMakeLists.txt | 231 +
+ libs/random/CMakeLists.txt | 28 +
+ libs/random/module.cmake | 3 +
+ libs/random/test/CMakeLists.txt | 34 +
+ libs/range/CMakeLists.txt | 28 +
+ libs/range/doc/CMakeLists.txt | 7 +
+ libs/range/module.cmake | 1 +
+ libs/range/test/CMakeLists.txt | 25 +
+ libs/rational/CMakeLists.txt | 28 +
+ libs/rational/module.cmake | 1 +
+ libs/rational/test/CMakeLists.txt | 14 +
+ libs/regex/CMakeLists.txt | 51 +
+ libs/regex/example/CMakeLists.txt | 76 +
+ libs/regex/module.cmake | 1 +
+ libs/regex/src/CMakeLists.txt | 51 +
+ libs/regex/test/CMakeLists.txt | 93 +
+ libs/serialization/CMakeLists.txt | 28 +
+ libs/serialization/module.cmake | 3 +
+ libs/serialization/src/CMakeLists.txt | 56 +
+ libs/serialization/test/CMakeLists.txt | 184 +
+ libs/signals/CMakeLists.txt | 29 +
+ libs/signals/module.cmake | 3 +
+ libs/signals/src/CMakeLists.txt | 13 +
+ libs/signals/test/CMakeLists.txt | 15 +
+ libs/signals2/CMakeLists.txt | 19 +
+ libs/signals2/module.cmake | 1 +
+ libs/signals2/test/CMakeLists.txt | 26 +
+ libs/smart_ptr/CMakeLists.txt | 36 +
+ libs/smart_ptr/module.cmake | 1 +
+ libs/smart_ptr/test/CMakeLists.txt | 56 +
+ libs/spirit/CMakeLists.txt | 30 +
+ libs/spirit/module.cmake | 1 +
+ libs/spirit/test/CMakeLists.txt | 121 +
+ libs/statechart/CMakeLists.txt | 27 +
+ libs/statechart/example/CMakeLists.txt | 31 +
+ libs/statechart/module.cmake | 1 +
+ libs/statechart/test/CMakeLists.txt | 93 +
+ libs/static_assert/CMakeLists.txt | 28 +
+ libs/static_assert/module.cmake | 1 +
+ libs/static_assert/test/CMakeLists.txt | 19 +
+ libs/system/CMakeLists.txt | 27 +
+ libs/system/module.cmake | 1 +
+ libs/system/src/CMakeLists.txt | 13 +
+ libs/test/CMakeLists.txt | 27 +
+ libs/test/build/Jamfile.v2 | 2 +-
+ libs/test/module.cmake | 5 +
+ libs/test/src/CMakeLists.txt | 70 +
+ libs/test/test/CMakeLists.txt | 49 +
+ libs/thread/CMakeLists.txt | 29 +
+ libs/thread/example/CMakeLists.txt | 17 +
+ libs/thread/module.cmake | 1 +
+ libs/thread/src/CMakeLists.txt | 20 +
+ libs/thread/test/CMakeLists.txt | 39 +
+ libs/timer/CMakeLists.txt | 28 +
+ libs/timer/module.cmake | 1 +
+ libs/timer/test/CMakeLists.txt | 9 +
+ libs/tokenizer/CMakeLists.txt | 27 +
+ libs/tokenizer/module.cmake | 1 +
+ libs/tokenizer/test/CMakeLists.txt | 15 +
+ libs/tr1/CMakeLists.txt | 27 +
+ libs/tr1/module.cmake | 1 +
+ libs/tr1/test/CMakeLists.txt | 75 +
+ libs/tuple/CMakeLists.txt | 27 +
+ libs/tuple/module.cmake | 2 +
+ libs/tuple/test/CMakeLists.txt | 11 +
+ libs/type_traits/CMakeLists.txt | 40 +
+ libs/type_traits/module.cmake | 1 +
+ libs/type_traits/test/CMakeLists.txt | 13 +
+ libs/typeof/CMakeLists.txt | 27 +
+ libs/typeof/module.cmake | 1 +
+ libs/typeof/test/CMakeLists.txt | 30 +
+ libs/units/CMakeLists.txt | 28 +
+ libs/units/doc/CMakeLists.txt | 8 +
+ libs/units/module.cmake | 2 +
+ libs/units/test/CMakeLists.txt | 70 +
+ libs/unordered/CMakeLists.txt | 29 +
+ libs/unordered/module.cmake | 1 +
+ libs/unordered/test/CMakeLists.txt | 24 +
+ libs/unordered/test/exception/CMakeLists.txt | 25 +
+ libs/unordered/test/unordered/CMakeLists.txt | 43 +
+ libs/utility/CMakeLists.txt | 37 +
+ libs/utility/enable_if/test/CMakeLists.txt | 20 +
+ libs/utility/module.cmake | 1 +
+ libs/utility/swap/test/CMakeLists.txt | 41 +
+ libs/utility/test/CMakeLists.txt | 47 +
+ libs/variant/CMakeLists.txt | 28 +
+ libs/variant/module.cmake | 1 +
+ libs/variant/test/CMakeLists.txt | 15 +
+ libs/wave/CMakeLists.txt | 28 +
+ libs/wave/module.cmake | 1 +
+ libs/wave/src/CMakeLists.txt | 24 +
+ libs/wave/test/CMakeLists.txt | 8 +
+ libs/xpressive/CMakeLists.txt | 27 +
+ libs/xpressive/module.cmake | 1 +
+ libs/xpressive/test/CMakeLists.txt | 84 +
+ tools/CMakeLists.txt | 122 +
+ tools/bcp/CMakeLists.txt | 32 +
+ tools/build/CMake/Boost.bmp | Bin 0 -> 71674 bytes
+ tools/build/CMake/Boost.png | Bin 0 -> 6308 bytes
+ tools/build/CMake/BoostConfig.cmake | 249 +
+ tools/build/CMake/BoostCore.cmake | 1509 +++++
+ tools/build/CMake/BoostDocs.cmake | 526 ++
+ tools/build/CMake/BoostExternals.cmake | 55 +
+ tools/build/CMake/BoostTesting.cmake | 494 ++
+ tools/build/CMake/BoostUtils.cmake | 275 +
+ tools/build/CMake/CMakeLists.txt | 91 +
+ tools/build/CMake/CTestCustom.cmake.in | 5 +
+ tools/build/CMake/CompileTest/CMakeLists.txt | 12 +
+ tools/build/CMake/FindICU.cmake | 51 +
+ tools/build/CMake/LinkTest/CMakeLists.txt | 26 +
+ tools/build/CMake/catalog.xml.in | 9 +
+ tools/build/CMake/docs/.gitignore | 4 +
+ tools/build/CMake/docs/Makefile.in | 101 +
+ tools/build/CMake/docs/build/html/.buildinfo | 4 +
+ tools/build/CMake/docs/build/html/_images/MacInstaller.png | Bin 0 -> 185943 bytes
+ tools/build/CMake/docs/build/html/_images/WindowsInstaller.png | Bin 0 -> 88166 bytes
+ tools/build/CMake/docs/build/html/_sources/add_boost_library.txt | 49 +
+ tools/build/CMake/docs/build/html/_sources/add_compiled_library.txt | 231 +
+ tools/build/CMake/docs/build/html/_sources/adding_regression_tests.txt | 107 +
+ tools/build/CMake/docs/build/html/_sources/build_configuration.txt | 289 +
+ tools/build/CMake/docs/build/html/_sources/build_installer.txt | 49 +
+ tools/build/CMake/docs/build/html/_sources/build_variants.txt | 275 +
+ tools/build/CMake/docs/build/html/_sources/diff.txt | 9 +
+ tools/build/CMake/docs/build/html/_sources/exported_targets.txt | 247 +
+ tools/build/CMake/docs/build/html/_sources/externals/bzip2.txt | 19 +
+ tools/build/CMake/docs/build/html/_sources/externals/doxygen.txt | 10 +
+ tools/build/CMake/docs/build/html/_sources/externals/expat.txt | 10 +
+ tools/build/CMake/docs/build/html/_sources/externals/icu.txt | 22 +
+ tools/build/CMake/docs/build/html/_sources/externals/index.txt | 44 +
+ tools/build/CMake/docs/build/html/_sources/externals/mpi.txt | 10 +
+ tools/build/CMake/docs/build/html/_sources/externals/python.txt | 88 +
+ tools/build/CMake/docs/build/html/_sources/externals/valgrind.txt | 27 +
+ tools/build/CMake/docs/build/html/_sources/externals/xsltproc.txt | 18 +
+ tools/build/CMake/docs/build/html/_sources/externals/zlib.txt | 17 +
+ tools/build/CMake/docs/build/html/_sources/faq.txt | 39 +
+ tools/build/CMake/docs/build/html/_sources/git.txt | 182 +
+ tools/build/CMake/docs/build/html/_sources/index.txt | 137 +
+ tools/build/CMake/docs/build/html/_sources/individual_libraries.txt | 152 +
+ tools/build/CMake/docs/build/html/_sources/install_customization.txt | 197 +
+ tools/build/CMake/docs/build/html/_sources/notes_by_version.txt | 218 +
+ tools/build/CMake/docs/build/html/_sources/quickstart.txt | 244 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_add_executable.txt | 132 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_add_library.txt | 192 +
+ .../CMake/docs/build/html/_sources/reference/boost_additional_test_dependencies.txt | 36 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_library_project.txt | 95 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_module.txt | 7 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_python_module.txt | 7 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_test_compile.txt | 6 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_test_compile_fail.txt | 6 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_test_run.txt | 7 +
+ tools/build/CMake/docs/build/html/_sources/reference/boost_test_run_fail.txt | 7 +
+ tools/build/CMake/docs/build/html/_sources/testing.txt | 428 ++
+ tools/build/CMake/docs/build/html/_static/alt.boost.png | Bin 0 -> 8906 bytes
+ tools/build/CMake/docs/build/html/_static/basic.css | 405 ++
+ tools/build/CMake/docs/build/html/_static/boost.css | 221 +
+ tools/build/CMake/docs/build/html/_static/contents.png | Bin 0 -> 202 bytes
+ tools/build/CMake/docs/build/html/_static/doctools.js | 232 +
+ tools/build/CMake/docs/build/html/_static/file.png | Bin 0 -> 392 bytes
+ tools/build/CMake/docs/build/html/_static/jquery.js | 32 +
+ tools/build/CMake/docs/build/html/_static/minus.png | Bin 0 -> 199 bytes
+ tools/build/CMake/docs/build/html/_static/navigation.png | Bin 0 -> 218 bytes
+ tools/build/CMake/docs/build/html/_static/plus.png | Bin 0 -> 199 bytes
+ tools/build/CMake/docs/build/html/_static/pygments.css | 59 +
+ tools/build/CMake/docs/build/html/_static/searchtools.js | 467 ++
+ tools/build/CMake/docs/build/html/_static/sphinxdoc.css | 349 +
+ tools/build/CMake/docs/build/html/add_boost_library.html | 146 +
+ tools/build/CMake/docs/build/html/add_compiled_library.html | 319 +
+ tools/build/CMake/docs/build/html/adding_regression_tests.html | 201 +
+ tools/build/CMake/docs/build/html/build_configuration.html | 359 +
+ tools/build/CMake/docs/build/html/build_installer.html | 139 +
+ tools/build/CMake/docs/build/html/build_variants.html | 371 +
+ tools/build/CMake/docs/build/html/diff.html | 1102 +++
+ tools/build/CMake/docs/build/html/exported_targets.html | 320 +
+ tools/build/CMake/docs/build/html/externals/bzip2.html | 127 +
+ tools/build/CMake/docs/build/html/externals/doxygen.html | 108 +
+ tools/build/CMake/docs/build/html/externals/expat.html | 108 +
+ tools/build/CMake/docs/build/html/externals/icu.html | 131 +
+ tools/build/CMake/docs/build/html/externals/index.html | 140 +
+ tools/build/CMake/docs/build/html/externals/mpi.html | 108 +
+ tools/build/CMake/docs/build/html/externals/python.html | 170 +
+ tools/build/CMake/docs/build/html/externals/valgrind.html | 128 +
+ tools/build/CMake/docs/build/html/externals/xsltproc.html | 124 +
+ tools/build/CMake/docs/build/html/externals/zlib.html | 124 +
+ tools/build/CMake/docs/build/html/faq.html | 130 +
+ tools/build/CMake/docs/build/html/genindex.html | 360 +
+ tools/build/CMake/docs/build/html/git.html | 278 +
+ tools/build/CMake/docs/build/html/index.html | 365 +
+ tools/build/CMake/docs/build/html/individual_libraries.html | 241 +
+ tools/build/CMake/docs/build/html/install_customization.html | 252 +
+ tools/build/CMake/docs/build/html/notes_by_version.html | 318 +
+ tools/build/CMake/docs/build/html/objects.inv | 6 +
+ tools/build/CMake/docs/build/html/quickstart.html | 338 +
+ tools/build/CMake/docs/build/html/reference/boost_add_executable.html | 210 +
+ tools/build/CMake/docs/build/html/reference/boost_add_library.html | 295 +
+ tools/build/CMake/docs/build/html/reference/boost_additional_test_dependencies.html | 142 +
+ tools/build/CMake/docs/build/html/reference/boost_library_project.html | 184 +
+ tools/build/CMake/docs/build/html/reference/boost_module.html | 103 +
+ tools/build/CMake/docs/build/html/reference/boost_python_module.html | 103 +
+ tools/build/CMake/docs/build/html/reference/boost_test_compile.html | 103 +
+ tools/build/CMake/docs/build/html/reference/boost_test_compile_fail.html | 103 +
+ tools/build/CMake/docs/build/html/reference/boost_test_run.html | 103 +
+ tools/build/CMake/docs/build/html/reference/boost_test_run_fail.html | 93 +
+ tools/build/CMake/docs/build/html/search.html | 100 +
+ tools/build/CMake/docs/build/html/searchindex.js | 1 +
+ tools/build/CMake/docs/build/html/testing.html | 516 ++
+ tools/build/CMake/docs/source/.gitignore | 1 +
+ tools/build/CMake/docs/source/GitLexer.py | 49 +
+ tools/build/CMake/docs/source/MacInstaller.png | Bin 0 -> 185943 bytes
+ tools/build/CMake/docs/source/WindowsInstaller.png | Bin 0 -> 88166 bytes
+ tools/build/CMake/docs/source/_static/boost.css | 221 +
+ tools/build/CMake/docs/source/_static/pygments.css | 59 +
+ tools/build/CMake/docs/source/_static/sphinxdoc.css | 349 +
+ tools/build/CMake/docs/source/_templates/layout.html | 7 +
+ tools/build/CMake/docs/source/add_boost_library.rst | 49 +
+ tools/build/CMake/docs/source/add_compiled_library.rst | 231 +
+ tools/build/CMake/docs/source/adding_regression_tests.rst | 107 +
+ tools/build/CMake/docs/source/alt.boost.png | Bin 0 -> 8906 bytes
+ tools/build/CMake/docs/source/boost-dark-trans.png | Bin 0 -> 8312 bytes
+ tools/build/CMake/docs/source/boost-small.png | Bin 0 -> 8899 bytes
+ tools/build/CMake/docs/source/boost.png | Bin 0 -> 6308 bytes
+ tools/build/CMake/docs/source/boost/theme.conf | 9 +
+ tools/build/CMake/docs/source/boost/todo.py | 147 +
+ tools/build/CMake/docs/source/boost_cmake_version.py.in | 2 +
+ tools/build/CMake/docs/source/build_configuration.rst | 289 +
+ tools/build/CMake/docs/source/build_installer.rst | 49 +
+ tools/build/CMake/docs/source/build_variants.rst | 275 +
+ tools/build/CMake/docs/source/cmake.py | 36 +
+ tools/build/CMake/docs/source/conf.py | 214 +
+ tools/build/CMake/docs/source/diff.rst | 9 +
+ tools/build/CMake/docs/source/exported_targets.rst | 247 +
+ tools/build/CMake/docs/source/externals/bzip2.rst | 19 +
+ tools/build/CMake/docs/source/externals/doxygen.rst | 10 +
+ tools/build/CMake/docs/source/externals/expat.rst | 10 +
+ tools/build/CMake/docs/source/externals/icu.rst | 22 +
+ tools/build/CMake/docs/source/externals/index.rst | 44 +
+ tools/build/CMake/docs/source/externals/mpi.rst | 10 +
+ tools/build/CMake/docs/source/externals/python.rst | 88 +
+ tools/build/CMake/docs/source/externals/valgrind.rst | 27 +
+ tools/build/CMake/docs/source/externals/xsltproc.rst | 18 +
+ tools/build/CMake/docs/source/externals/zlib.rst | 17 +
+ tools/build/CMake/docs/source/faq.rst | 39 +
+ tools/build/CMake/docs/source/git.rst | 182 +
+ tools/build/CMake/docs/source/git_diff.txt | 1 +
+ tools/build/CMake/docs/source/index.rst | 138 +
+ tools/build/CMake/docs/source/individual_libraries.rst | 152 +
+ tools/build/CMake/docs/source/install_customization.rst | 197 +
+ tools/build/CMake/docs/source/modularize_library.rst.set_aside | 183 +
+ tools/build/CMake/docs/source/notes_by_version.rst | 218 +
+ tools/build/CMake/docs/source/quickstart.rst | 244 +
+ tools/build/CMake/docs/source/reference/boost_add_executable.rst | 132 +
+ tools/build/CMake/docs/source/reference/boost_add_library.rst | 192 +
+ tools/build/CMake/docs/source/reference/boost_additional_test_dependencies.rst | 36 +
+ tools/build/CMake/docs/source/reference/boost_library_project.rst | 95 +
+ tools/build/CMake/docs/source/reference/boost_module.rst | 7 +
+ tools/build/CMake/docs/source/reference/boost_python_module.rst | 7 +
+ tools/build/CMake/docs/source/reference/boost_test_compile.rst | 6 +
+ tools/build/CMake/docs/source/reference/boost_test_compile_fail.rst | 6 +
+ tools/build/CMake/docs/source/reference/boost_test_run.rst | 7 +
+ tools/build/CMake/docs/source/reference/boost_test_run_fail.rst | 7 +
+ tools/build/CMake/docs/source/testing.rst | 428 ++
+ tools/build/CMake/externals/BZip2.cmake | 11 +
+ tools/build/CMake/externals/Doxygen.cmake | 13 +
+ tools/build/CMake/externals/Expat.cmake | 13 +
+ tools/build/CMake/externals/ICU.cmake | 12 +
+ tools/build/CMake/externals/MPI.cmake | 11 +
+ tools/build/CMake/externals/Python.cmake | 161 +
+ tools/build/CMake/externals/Python/valgrind-python-2.4.6.supp | 228 +
+ tools/build/CMake/externals/Python/valgrind-python-2.6.4.supp | 403 ++
+ tools/build/CMake/externals/Python/valgrind-python-3.1.1.supp | 391 ++
+ tools/build/CMake/externals/Valgrind.cmake | 18 +
+ tools/build/CMake/externals/Xsltproc.cmake | 18 +
+ tools/build/CMake/externals/ZLib.cmake | 13 +
+ tools/build/CMake/install_me/Boost-thisversion.cmake.in | 75 +
+ tools/build/CMake/install_me/BoostConfig.cmake.in | 80 +
+ tools/build/CMake/install_me/BoostConfigAgnostic.cmake.in | 19 +
+ tools/build/CMake/install_me/BoostConfigVersion.cmake.in | 22 +
+ tools/build/CMake/install_me/BoostConfigVersionAgnostic.cmake.in | 69 +
+ tools/build/CMake/install_me/version.hpp.override.in | 35 +
+ tools/build/CMake/main.cpp | 7 +
+ tools/build/CMake/test/include/selftest_lib.ipp | 22 +
+ tools/build/CMake/test/include/selftest_main.ipp | 11 +
+ tools/build/CMake/test/include/selftest_report.hpp | 6 +
+ tools/build/CMake/test/libs/a/CMakeLists.txt | 27 +
+ tools/build/CMake/test/libs/a/module.cmake | 1 +
+ tools/build/CMake/test/libs/a/src/CMakeLists.txt | 38 +
+ tools/build/CMake/test/libs/a/src/lib.cpp | 22 +
+ tools/build/CMake/test/libs/a/src/main.cpp | 1 +
+ tools/build/CMake/test/libs/a/test/CMakeLists.txt | 21 +
+ tools/build/CMake/test/libs/b/CMakeLists.txt | 27 +
+ tools/build/CMake/test/libs/b/module.cmake | 1 +
+ tools/build/CMake/test/libs/b/src/CMakeLists.txt | 30 +
+ tools/build/CMake/test/libs/b/src/lib.cpp | 1 +
+ tools/build/CMake/test/libs/b/src/main.cpp | 1 +
+ tools/build/CMake/test/libs/b/test/CMakeLists.txt | 21 +
+ tools/build/CMake/test/libs/c/CMakeLists.txt | 27 +
+ tools/build/CMake/test/libs/c/src/CMakeLists.txt | 30 +
+ tools/build/CMake/test/libs/c/src/lib.cpp | 22 +
+ tools/build/CMake/test/libs/c/src/main.cpp | 12 +
+ tools/build/CMake/test/libs/c/test/CMakeLists.txt | 21 +
+ tools/build/CMake/test/tools/tool-a/CMakeLists.txt | 36 +
+ tools/build/CMake/test/tools/tool-a/main.cpp | 11 +
+ tools/build/CMake/test/tools/tool-a/module.cmake | 1 +
+ tools/build/CMake/test/tools/tool-a/src/CMakeLists.txt | 36 +
+ tools/build/CMake/test/tools/tool-a/src/lib.cpp | 17 +
+ tools/build/CMake/test/tools/tool-a/src/main.cpp | 10 +
+ tools/build/CMake/test/tools/tool-a/test/CMakeLists.txt | 21 +
+ tools/build/CMake/test/tools/tool-b/CMakeLists.txt | 35 +
+ tools/build/CMake/test/tools/tool-b/main.cpp | 10 +
+ tools/build/CMake/test/tools/tool-b/module.cmake | 1 +
+ tools/build/CMake/test/tools/tool-b/src/CMakeLists.txt | 28 +
+ tools/build/CMake/test/tools/tool-b/src/lib.cpp | 17 +
+ tools/build/CMake/test/tools/tool-b/src/main.cpp | 10 +
+ tools/build/CMake/test/tools/tool-b/test/CMakeLists.txt | 21 +
+ tools/inspect/CMakeLists.txt | 20 +
+ tools/jam/src/.gitignore | 3 +
+ tools/quickbook/CMakeLists.txt | 33 +
+ tools/wave/CMakeLists.txt | 22 +
+ 500 files changed, 32214 insertions(+), 13 deletions(-)
+
+Boost.CMake exports its targets, making developing independent +projects against an installed boost, or simply against a build tree +sitting on disk. There are a variety of ways to use these to ease +configuration of boost in your external project.
+You only need to do three things:
+Add the appropriate include directory with +include_directories(). This is the toplevel of the boost +source tree.
+include the generated Exports.cmake from the build tree +containing the exported targets. I is located in +${CMAKE_BINARY_DIR}/lib/Exports.cmake
+Tell cmake about your link dependencies with +target_link_libraries. Note that you use the names of the +cmake targets, not the shorter names that the libraries have on +disk. make help shows a list:
+% make help | grep signals
+... boost_signals
+... boost_signals-mt-shared
+... boost_signals-mt-shared-debug
+... boost_signals-mt-static
+... boost_signals-mt-static-debug
+See also Name Mangling for details on the naming +conventions.
+Since these are exported targets, CMake will add appropriate rpaths +as necessary; fiddling with LD_LIBRARY_PATH should not be +necessary.
+If you get the target name wrong, cmake will assume that you are +talking about a library in the linker’s default search path, not an +imported target name and you will get an error when cmake tries to +link against the nonexistent target. For instance, if I specify:
+target_link_libraries(main boost_thread-mt-d)
+on linux my error will be something like:
+[100%] Building CXX object CMakeFiles/main.dir/main.cpp.o
+Linking CXX executable main
+/usr/bin/ld: cannot find -lboost_thread-mt-d
+collect2: ld returned 1 exit status
+The problem here is that the real name of the multithreaded, shared, +debug library target is boost_thread-mt-shared-debug. I know this is +confusing; much of this is an attempt to be compatible with +boost.build.
+If you are having trouble, have a look inside that file +Exports.cmake. For each available target, you’ll see:
+# Create imported target boost_thread-mt-shared-debug
+ADD_LIBRARY(boost_thread-mt-shared-debug SHARED IMPORTED)
+
+# Import target "boost_thread-mt-shared-debug" for configuration "Release"
+SET_PROPERTY(TARGET boost_thread-mt-shared-debug APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
+SET_TARGET_PROPERTIES(boost_thread-mt-shared-debug PROPERTIES
+ IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE "pthread;rt"
+ IMPORTED_LOCATION_RELEASE "/home/troy/Projects/boost/cmake/cmaketest/build/boost/lib/libboost_thread-mt-d.so.1.41.0"
+ IMPORTED_SONAME_RELEASE "libboost_thread-mt-d.so.1.41.0"
+ )
+it is the name in the ADD_LIBRARY line that you pass to +target_link_libraries().
+There is an unpacked boost in /home/troy/boost-1.41.0/src and +built boost in directory /home/troy/boost/1.41.0/build. I have a +program that builds from one file, main.cpp and uses boost +threads. My CMakeLists.txt looks like this:
+include_directories(
+ /home/troy/boost-1.41.0/src
+ /home/troy/boost-1.41.0/build/lib/Exports.cmake
+ )
+
+add_executable(my_program main.cpp)
+
+target_link_libraries(my_program boost_thread-mt-shared-debug)
+When I build, I see +(wrapped, and some output replaced with ... for brevity):
+% make VERBOSE=1
+...
+[100%] Building CXX object CMakeFiles/main.dir/main.cpp.o
+/usr/bin/c++ -I/home/troy/boost-1.41.0/src -o CMakeFiles/main.dir/main.cpp.o -c /home/troy/myproject/main.cpp
+...
+linking CXX executable main
+/usr/bin/c++ -fPIC CMakeFiles/main.dir/main.cpp.o -o main -rdynamic /home/troy/boost-1.41.0/build/lib/libboost_thread-mt-d.so.1.41.0 -lpthread -lrt -Wl,-rpath,/home/troy/boost-1.41.0/build/lib
+...
+[100%] Built target main
+The process by which cmake discovers an installed boost is a big +topic, outside the scope of this document. Boost.CMake makes every +effort to install things cleanly and behave in a backwards-compatible +manner.
+The variable BOOST_INSTALL_CMAKE_DRIVERS controls whether +Boost.CMake installs two files which help out in case multiple +versions of boost are installed. If there is only one version +present, the situation is simpler: typically this is simply a +matter of either installing boost to a directory that on cmake’s +built-in CMAKE_PREFIX_PATH, or adding the directory to +CMAKE_PREFIX_PATH in your environment if it is not. You can see +built-in search path by running cmake --system-information and +looking for CMAKE_SYSTEM_PREFIX_PATH.
+Make a subdirectory for your project and create a file main.cpp:
+#include <iostream>
+#include <boost/version.hpp>
+#include <boost/thread/thread.hpp>
+
+void helloworld()
+{
+ std::cout << BOOST_VERSION << std::endl;
+}
+
+int main()
+{
+ boost::thread thrd(&helloworld);
+ thrd.join();
+}
+Create a CMakeLists.txt in the same directory containing the +following:
+find_package(Boost 1.41.0 COMPONENTS thread NO_MODULE)
+ ^^^^^^^^^--- NOTE THIS
+include(${Boost_INCLUDE_DIR})
+add_executable(main main.cpp)
+target_link_libraries(main ${Boost_LIBRARIES})
+The NO_MODULE above is currently required, pending updates to +FindBoost.cmake in a cmake release.
+Then run cmake . in that directory (note the dot). Then run make. +If all is well you will see:
+% make VERBOSE=1
+...
+[100%] Building CXX object CMakeFiles/main.dir/main.cpp.o
+/usr/bin/c++ -I/usr/local/boost-1.41.0/include -o CMakeFiles/main.dir/main.cpp.o -c /home/troy/Projects/boost/cmake/proj/main.cpp
+...
+Linking CXX executable main
+/usr/bin/c++ -fPIC CMakeFiles/main.dir/main.cpp.o -o main -rdynamic /usr/local/boost-1.41.0/lib/libboost_thread-mt-d.so.1.41.0 -lpthread -lrt -Wl,-rpath,/usr/local/boost-1.41.0/lib
+...
+[100%] Built target main
+If all is not well, set CMAKE_PREFIX_PATH in your environment or in +your CMakeLists.txt. Add the CMAKE_INSTALL_PREFIX that you used +when you installed boost:
+export CMAKE_PREFIX_PATH=/my/unusual/location
+and try again.
+If the above didn’t work, you can help cmake find your boost +installation by setting Boost_DIR (in your CMakeLists.txt to +the BOOST_CMAKE_INFRASTRUCTURE_INSTALL_DIR that was set when you +compiled. Boost_DIR will override any other settings.
+Given a (versioned) boost installation in /net/someplace, +Your CMakeLists.txt would look like this:
+include_directories(/net/someplace/include/boost-1.41.0)
+
+# you can also set Boost_DIR in your environment
+set(Boost_DIR /net/someplace/share/boost-1.41.0/cmake)
+
+find_package(Boost NO_MODULE)
+
+add_executable(main main.cpp)
+
+target_link_libraries(main boost_thread-mt-shared-debug)
+The only recommended way to do this is the following:
+At this point passing a version argument to find_package (see also +docs for FindBoost.cmake) should result in correct behavior.
+Footnotes
+| [1] | If your distribution specifies a LIB_SUFFIX +(e.g. if it installs libraries to +${CMAKE_INSTALL_PREFIX/lib64, you +will find Boost.cmake there. If the installation is +‘versioned’, the Boost.cmake file may be in a +versioned subdirectory of lib, e.g. lib/boost-1.41.0. |
If WITH_BZIP2 is ON, BZip2 is detected via the standard cmake +find_package(BZip2). The following variables are set:
+| BZIP2_FOUND | +Bzip2 was found | +
| BZIP2_INCLUDE_DIR | +Path to BZip2 includes | +
| BZIP2_DEFINITIONS | +Compile line flags for BZip2 | +
| BZIP2_LIBRARIES | +Libraries to link to when using BZip2 | +
If WITH_DOXYGEN is ON, doxygen is detected via the standard +cmake find_package(Doxygen). See the cmake documentation for more +information
+If WITH_EXPAT is ON, expat is detected via the standard +cmake find_package(Expat). See the cmake documentation for more +information
+If WITH_ICU is ON, ICU is detected via the standard cmake +find_package(ICU). The following variables are set:
+| ICU_FOUND | +ON if icu was found | +
| ICU_I18N_FOUND | +ON if the i18n part (whatever that is) +of ICU was found. | +
| ICU_INCLUDE_DIRS | +path to ICU headers | +
| ICU_LIBRARIES | +full paths to ICU libraries | +
| ICU_I18N_LIBRARIES | +full paths to the i18n libraries | +
Each external dependency has an associated option WITH_dependency that controls whether detection of the dependency will +happen at all. These options default to ON.
+Each external will set a variable external_FOUND if detection +was successful. If this variable is empty (or FALSE, 0, or +NO) detection will be reattempted each time you configure.
+To disable the detection of any given external dependency and +thereby any libraries or features that depend on it, set option +WITH_dependency to NO (or OFF, etc.):
+
+ % cmake ../src -DWITH_PYTHON=OFF
+-- The C compiler identification is GNU
+-- The CXX compiler identification is GNU
+... more output ...
+--
+-- Python:
+-- Disabled since WITH_PYTHON=OFF
+--
+... more output ...
+-- + python
+-- +-- disabled since PYTHON_FOUND is false
+--
+If WITH_MPI is ON, MPI is detected via the standard +cmake find_package(MPI). See the cmake documentation for more +information.
+By default, Boost.CMake will use the python detection built in to +cmake. The relevant variables (command line or environment) are:
+The path to the python executable, e.g. /usr/local/Python-3.1.1/bin/python3
+The path to the python debug library, typically only used by developers.
+The path to the python library, +e.g. /usr/local/Python-3.1.1/lib/libpython3.1.so
+The path to the include directory, +e.g. /usr/local/Python-3.1.1/include/python3.1. Note that cmake +will check for the file Python.h in this directory and complain if +it is not found.
+There are two ways to specify these, on the command line or via +environment variables. Environment variables will override command +line flags if present.
+Command line
+% cmake ../src -DPYTHON_EXECUTABLE=/path/to/bin/python3 \
+ -DPYTHON_LIBRARIES=/path/to/libpython3.1.so \
+ -DPYTHON_INCLUDE_PATH=/path/to/include/python3.1
+Exported environment variables
+% export PYTHON_EXECUTABLE=/path/to/bin/python
+% export PYTHON_LIBRARIES=/path/to/libpython3.1.so
+% export PYTHON_INCLUDE_PATH=/path/to/include/python3.1
+% cmake ../src
+Either way, in the configuration output, you should see something +like:
+-- Testing PYTHON_EXECUTABLE from environment
+-- Ok, using /path/to/bin/python3
+-- Testing PYTHON_LIBRARIES from environment
+-- Ok, using /path/to/lib/libpython3.1.so.
+-- Skipping optional PYTHON_DEBUG_LIBRARIES: not set.
+-- Testing PYTHON_INCLUDE_PATH from environment
+-- Ok, using /path/to/include/python3.1
+-- Python:
+-- executable: /path/to/bin/python3
+-- lib: /path/to/lib/libpython3.1.so
+-- debug lib:
+-- include path: /path/to/include/python3.1
+NOTE, once successfully detected, the python configuration will +not be redetected. To modify, edit the relevant entries in your +CMakeCache.txt, or delete it entirely to trigger redetection.
+Boost.cmake does a standard path search for valgrind. If found, +it sets the following variables
+| VALGRIND_FOUND | +Was valgrind found | +
| VALGRIND_FLAGS | +“–tool=memcheck” | +
| VALGRIND_EXECUTABLE | +path to the executable | +
If the setting WITH_VALGRIND is ON, (see +External Dependencies) then tests will be run under valgrind. +Tip: CTest’s -V flag will show you the exact commands run and +output of each test.
+Boost.cmake does a standard path search for xsltproc. If found, +it sets the following variables
+| XSLTPROC_FOUND | +Was xsltproc found | +
| XSLTPROC_FLAGS | +“–xinclude” | +
| XSLTPROC_EXECUTABLE | +path to the executable | +
If WITH_ZLIB is ON, Zlib is detected via the standard cmake +find_package(Zlib). The following variables are set:
+| ZLIB_FOUND | +Zlib was found | +
| ZLIB_INCLUDE_DIR | +Path to Zlib includes | +
| ZLIB_LIBRARIES | +Libraries to link to when using Zlib | +
A collection of asked questions.
+Note: I couldn’t find the magic checkbox to tell visual studio show me +what commands it executes while building. I switched the cmake gui to +‘advanced mode’ and change CMAKE_VERBOSE_MAKEFILES to TRUE. Is there a +more ‘visualstudioesque’ way to do this?
+-t
+See Customizing the install for more information about variables +used in this section.
+If you plan on using the FindBoost.cmake packaged with cmake +versions 2.8.0 and earlier, (that is, third party packages that build +with cmake need to find this boost installation via the cmake command +find_package(Boost...), you will need to layout your boost +installation in a way that is consistent with the way boost was +installed by bjam during the many Dark Years. Michael Jackson of +bluequartz.net reports success with the configuration below. He +refers to boost.cmake variables INSTALL_VERSIONED, +BOOST_INCLUDE_INSTALL_DIR, and BOOST_LIB_INSTALL_DIR:
+> Set INSTALL_VERSIONED=OFF
+> set BOOST_INCLUDE_INSTALL_DIR=include/boost-1_41
+> set BOOST_LIB_INSTALL_DIR=lib
+>
+> and then go. I also set an environment variable BOOST_ROOT to the
+> CMAKE_INSTALL_PREFIX.
+>
+> In my CMake file I have the following;
+>
+> # ---------- Find Boost Headers/Libraries -----------------------
+> SET (Boost_FIND_REQUIRED TRUE)
+> SET (Boost_FIND_QUIETLY TRUE)
+> set (Boost_USE_MULTITHREADED TRUE)
+> set (Boost_USE_STATIC_LIBS TRUE)
+> SET (Boost_ADDITIONAL_VERSIONS "1.41" "1.41.0")
+>
+> if ( NOT MXA_BOOST_HEADERS_ONLY)
+> set (MXA_BOOST_COMPONENTS program_options unit_test_framework
+> test_exec_monitor)
+> endif()
+> FIND_PACKAGE(Boost COMPONENTS ${MXA_BOOST_COMPONENTS} )
+> INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
+> LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
+>
+> This successfully works with the FindBoost.cmake that is included with CMake 2.6.4
+>
+Currently in development there are other, perhaps easier, ways to +detect your boost installations if you aren’t dependent on this older +FindBoost; see Tricks for Building against Boost with CMake.
+
+
|
|
| + |
| + |
| + |
| + |
+
|
| + |
|
| + |
|
+
|
|
+
|
|
+
|
|
| + |
| + |
| + |
| + |
| + |
|
| + |
|
| + |
|
+
|
|
+
|
|
Differences between this release and upstream
+Boost-cmake, in addition to using an alternative build system, uses +alternate version control. This makes boost.cmake feasable: without +distributed version control it would be very difficult to maintain a +build system against upstream boost.
+This document will review some common version-control procedures for +those who are unfamiliar with git. More documentation is available at +Hacking Boost via Git.
+The first step is to get Git. Any recent +version will do. On windows, git downloads come with a bash shell, so +the commandline interface is essentially identical. There is also +TortoiseGit, which is +evolving quickly and quite usable.
+Pick some directory to work in. Here I’ll use /tmp. My prompt is +a percent sign. Clone the repository to a subdirectory called +src. This will take a while the first time, after that things +will be very fast.
+% git clone git://gitorious.org/boost/cmake.git src
+Initialized empty Git repository in /tmp/src/.git/
+remote: Counting objects: 425396, done.
+remote: Compressing objects: 100% (129689/129689), done.
+remote: Total 425396 (delta 298454), reused 419119 (delta 292368)
+Receiving objects: 100% (425396/425396), 135.56 MiB | 1260 KiB/s, done.
+Resolving deltas: 100% (298454/298454), done.
+Checking out files: 100% (23865/23865), done.
+inside this directory you’ll see the branch that is checked out:
+% cd src
+% git branch -l
+* 1.41.0
+This means I’m on the 1.41.0 branch, and the files are checked +out:
+% ls
+CMakeLists.txt boost/ bootstrap.sh* libs/ tools/
+CTestConfig.cmake boost-build.jam build/ more/ wiki/
+INSTALL boost.css doc/ people/
+Jamroot boost.png index.htm rst.css
+LICENSE_1_0.txt bootstrap.bat index.html status/
+Now you can go ahead and do your out-of-source build.
+When new changes arrive upstream, you’ll want to git pull:
+% git pull
+remote: Counting objects: 310, done.
+remote: Compressing objects: 100% (45/45), done.
+remote: Total 205 (delta 154), reused 203 (delta 152)
+Receiving objects: 100% (205/205), 49.59 KiB, done.
+Resolving deltas: 100% (154/154), completed with 81 local objects.
+From git://gitorious.org/boost/cmake
+ 1818334..b945719 1.41.0 -> origin/1.41.0
+Updating 1818334..b945719
+Fast forward
+ CMakeLists.txt | 6 +-
+ CTestConfig.cmake | 5 +-
+...
+ 83 files changed, 1071 insertions(+), 537 deletions(-)
+git branch -r will show your ‘remote’ branches:
+% git branch -r
+ origin/1.40.0
+ origin/1.41.0
+ origin/HEAD -> origin/1.41.0
+ origin/master
+This shows that in origin (the repository you cloned from), there +are 1.40.0, 1.41.0, and master branches. To switch to e.g. the +1.40.0 branch, you make a local branch that ‘tracks’ the upstream +branch:
+% git checkout -b 1.40.0 origin/1.40.0
+Branch 1.40.0 set up to track remote branch 1.40.0 from origin.
+Switched to a new branch '1.40.0'
+Now you will see this new local branch in your branch list:
+% git branch -l
+* 1.40.0 # the star means this one is checked out
+ 1.41.0
+And your status will show it as well:
+% git status
+# On branch 1.40.0
+nothing to commit (working directory clean)
+now, any git pull-ing you do will come from the upstream 1.40.0 +branch in to your local 1.40.0 branch.
+Just change the files and git diff:
+% git diff
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index d2bc809..d5e055e 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -27,6 +27,10 @@
+ cmake_minimum_required(VERSION 2.6.4 FATAL_ERROR)
+ project(Boost)
+
++#
++# These are my changes
++#
++
+ ##########################################################################
+ # Version information #
+ ##########################################################################
+@@ -323,6 +327,7 @@ endif()
+
+ mark_as_advanced(BOOST_EXPORTS_FILE BOOST_INSTALL_EXPORTS_FILE)
+
++# and some here too
+ # Add build rules for documentation
+ add_subdirectory(doc)
+and mail it in.
+Use git reset:
+% git reset --hard HEAD
+HEAD is now at e26008e Don't build tools by default. All they do is break.
+If you’ve already created a local branch, i.e. it appears in the +output of git branch -l:
+% git branch -l
+* 1.40.0
+ 1.41.0
+Then just check it out:
+% git checkout 1.41.0
+Switched to branch '1.41.0'
+
+% git branch -l
+ 1.40.0
+* 1.41.0
+
+% git status
+# On branch 1.41.0
+nothing to commit (working directory clean)
+If not (i.e. it only appears in the output of git branch -r), +see But I want a different branch than that.
+Boost.CMake (or alt.boost) is the boost distribution that all the cool kids are +using. The effort started in earnest at BoostCon ‘07; by the end of which it was possible to do +a basic build of boost with cmake. In 2009, the project moved out to +git version control. Today, Boost.CMake is stable, mature, and +supported by the developers, a large base of expert users, and +occasionally by the authors of CMake itself.
+boost-cmake mailing list
++http://lists.boost.org/mailman/listinfo.cgi/boost-cmake+
IRC
++#boost-cmake on the freenode network+
CMake home page
++http://www.cmake.org+
Source code
++Boost.CMake is distributed separately from upstream boost. Code +is in a git repository at +http://gitorious.org/boost/cmake.git. These documents correspond to +tag 1.41.0.cmake0. See also Hacking Boost.CMake with Git.+
Tarballs
++Tarballs and zipfiles are available at +http://sodium.resophonic.com/boost-cmake/ in subdirectory 1.41.0.cmake0.+
This documentation was created with Sphinx.
+The source is in the restructuredtext files in subdirectory +tools/build/CMake/docs/source/. Hack on them (see the +documentation for Sphinx). +When you’re ready to see the html:
+make html
+Once you’ve written a ton of docs, push them someplace where I can see +them (or use git diff to send a patch).
+The ‘alt’ is a reference to the alt.* Usenet hierarchy. Here, as +in Usenet, alt stands for Anarchists, Lunatics and Terrorists. This independent effort explores +and applies alternate techniques/technologies in the areas of build, +version control, testing, packaging, documentation and release +management.
+Differences between this release and upstream
+In a configured cmake workspace, make help will display a list of available targets. Example:
+% make help
+The following are some of the valid targets for this Makefile:
+... all (the default if no target is provided)
+... clean
+... depend
+... edit_cache
+... install
+... install/local
+... install/strip
+... list_install_components
+... package
+... package_source
+... rebuild_cache
+... boost_date_time
+... boost_date_time-mt-shared
+... boost_date_time-mt-shared-debug
+... boost_date_time-mt-static
+... boost_date_time-mt-static-debug
+... boost_date_time-shared
+... boost_date_time-shared-debug
+... boost_date_time-static
+... boost_date_time-static-debug
+... boost_filesystem
+... boost_filesystem-mt-shared
+... boost_filesystem-mt-shared-debug
+... boost_filesystem-mt-static
+... boost_filesystem-mt-static-debug
+... boost_filesystem-shared
+... boost_filesystem-shared-debug
+... boost_filesystem-static
+... boost_filesystem-static-debug
+[etc]
+You can build any target by passing it as an argument:
+% make boost_signals-static
+[ 0%] Building CXX object libs/signals/src/CMakeFiles/boost_signals-static.dir/trackable.cpp.o
+[ 0%] Building CXX object libs/signals/src/CMakeFiles/boost_signals-static.dir/connection.cpp.o
+[100%] Building CXX object libs/signals/src/CMakeFiles/boost_signals-static.dir/named_slot_map.cpp.o
+[100%] Building CXX object libs/signals/src/CMakeFiles/boost_signals-static.dir/signal_base.cpp.o
+[100%] Building CXX object libs/signals/src/CMakeFiles/boost_signals-static.dir/slot.cpp.o
+Linking CXX static library ../../../lib/libboost_signals-gcc41-1_35.a
+[100%] Built target boost_signals-static
+In build directories corresponding to a source library containing a +CMakeLists.txt containing a boost_add_library invocation +(e.g. build/libs/signals/src, build/libs/filesystem/src), more +detailed targets are available:
+% cd libs/signals/src
+% make help
+The following are some of the valid targets for this Makefile:
+ [many omitted]
+... signal_base.o
+... signal_base.i
+... signal_base.s
+... slot.o
+... slot.i
+... slot.s
+making slot.i will run slot.cpp through the preprocessor:
+% make slot.i
+Preprocessing CXX source to CMakeFiles/boost_signals-mt-shared.dir/slot.cpp.i
+If you are always interested in seeing the compiler flags you can +enable CMAKE_VERBOSE_MAKEFILES via ccmake, or for a one-off +just pass VERBOSE=1 on the command line:
+% make VERBOSE=1 slot.i
+make[1]: Entering directory `/home/troy/Projects/boost/branches/CMake/Boost_1_35_0-build'
+Preprocessing CXX source to CMakeFiles/boost_signals-mt-shared.dir/slot.cpp.i
+cd /home/troy/Projects/boost/branches/CMake/Boost_1_35_0-build/libs/signals/src && /usr/bin/gcc-4.1
+-DBOOST_ALL_NO_LIB=1 -DBOOST_SIGNALS_NO_LIB=1 -Dboost_signals_mt_shared_EXPORTS -fPIC
+-I/home/troy/Projects/boost/branches/CMake/Boost_1_35_0 -O3 -DNDEBUG -DBOOST_SIGNALS_DYN_LINK=1
+-pthread -D_REENTRANT -E /home/troy/Projects/boost/branches/CMake/Boost_1_35_0/libs/signals/src/slot.cpp > CMakeFiles/boost_signals-mt-shared.dir/slot.cpp.i
+Tests and examples are typically grouped into subdirectories, e.g.:
+libs/
+ iostreams/
+ test/
+ examples/
+CMake builds a parallel directory hierarchy in the build directory. If +you are working on, say, the examples for iostreams, you can just +cd into the directory $BUILDDIR/libs/iostreams/examples and type +make:
+% cd libs/iostreams/example
+% make
+[ 0%] Built target boost_iostreams-mt-static
+Scanning dependencies of target iostreams-examples-boost_back_inserter_example
+[ 0%] Building CXX object libs/iostreams/example/CMakeFiles/iostreams-examples-boost_back_inserter_example.dir/boost_back_inserter_example.cpp.o
+Linking CXX executable ../../../bin/iostreams-examples-boost_back_inserter_example
+[ 0%] Built target iostreams-examples-boost_back_inserter_example
+Scanning dependencies of target iostreams-examples-container_device_example
+[ 0%] Building CXX object libs/iostreams/example/CMakeFiles/iostreams-examples-container_device_example.dir/container_device_example.cpp.o
+Linking CXX executable ../../../bin/iostreams-examples-container_device_example
+[ 0%] Built target iostreams-examples-container_device_example
+Scanning dependencies of target iostreams-examples-container_sink_example
+[ 0%] Building CXX object libs/iostreams/example/CMakeFiles/iostreams-examples-container_sink_example.dir/container_sink_example.cpp.o
+If you find yourself working on a compiler error in a file that takes +a long time to compile, waiting for make to check all of the +prerequisites might become tedious. You can have make skip the +prerequisite testing (you do this at your own risk), by appending +/fast to the target name. For instance, bcp depends on the +system, filesystem regex and prg_exec_monitor +libraries:
+% cd tools/bcp
+% make bcp
+[ 0%] Built target boost_system-mt-static
+[ 0%] Built target boost_filesystem-mt-static
+[ 50%] Built target boost_regex-mt-static
+[ 75%] Built target boost_prg_exec_monitor-mt-static
+[ 75%] Building CXX object tools/bcp/CMakeFiles/bcp.dir/add_path.cpp.o
+if I make bcp/fast, the dependencies are assumed to be built +already:
+% make bcp/fast
+[ 75%] Building CXX object tools/bcp/CMakeFiles/bcp.dir/add_path.cpp.o
+[ 75%] Building CXX object tools/bcp/CMakeFiles/bcp.dir/bcp_imp.cpp.o
+(etc)
+Tricks for Building against Boost with CMake
+Here you’ll find ways to customize your installation. If you’re +trying to make the install play nice with cmake’s find_package, +see find_package(Boost).
+This is a standard cmake option that sets the path to which boost +will be installed.
+CMake generates makefiles that play nice with DESTDIR. e.g. +if you configure like this:
+cmake ../src -DCMAKE_INSTALL_PREFIX=/tmp/blah
+and install with DESTDIR=/foo make install, you’ll get files +installed to /foo/tmp/blah.
+This defines the subdirectory of CMAKE_INSTALL_PREFIX to which +libraries will be installed. It is empty by default. For example, +if I’m on 64-bit fedora, I want the libs installed to +/usr/lib64, I’d use:
+cmake ../src -DCMAKE_INSTALL_PREFIX=/usr -DLIB_SUFFIX=64
+ON by default on unix, OFF on windows.
+This is a different mangling than WINMANGLE_LIBNAMES: this +variable controls whether boost versions will be mangled into the +paths into which boost is installed. This option has effect only +when CMake is run the first time: they will be set as explained +below the first time thereafter not modified, so that the paths are +customizable by users. (ie If you have configured a build and change +this option, it will have no effect, you must start “from scratch”)
+Example
+For boost version 1.41.0, with this option ON, the installation tree +is:
+$CMAKE_INSTALL_PREFIX/
+ include/
+ boost-1.41.0/
+ boost/
+ version.hpp
+ ...
+ lib/
+ boost-1.41.0/
+ libboost_signals-mt-d.so
+ ...
+and without it,
+$CMAKE_INSTALL_PREFIX/
+ include/
+ boost/
+ version.hpp
+ ...
+ lib/
+ boost/
+ libboost_signals-mt-d.so
+ ...
+Note: lib/ above will contain LIB_SUFFIX if set.
+See also BUILD_SOVERSIONED
+The relative lib and include pathnames can be controlled individually +with the following two variables:
+The directory to which libs will be installed under +CMAKE_INSTALL_PREFIX.
+The directory to which boost header files will be installed under +CMAKE_INSTALL_PREFIX.
+This is a directory to which the targets from this boost install will +be exported, by default ${CMAKE_INSTALL_PREFIX}/share/boost-1.41.0/cmake: this significanly eases detection of boost +installations by CMake. The name of the files are +BoostConfig.cmake and BoostConfigVersion.cmake [1]. +See Tricks for Building against Boost with CMake for +more information about how users employ this file.
+If this is a full path, it will be used directly, otherwise it will be +interpreted relative to ${CMAKE_INSTALL_PREFIX}.
+Specifies whether generic cmake driver files should be installed, +see the next option to customize where. This variable is +ON by default.
+There are two optional version-agnostic driver files that can be +installed to a central location, by default +${CMAKE_INSTALL_PREFIX}/share/boost-1.41.0/cmake.
+named BoostConfig.cmake and BoostConfigVersion.cmake. These +two files coordinate with Boost-1.41.0.cmake to enable cmake +developers who use both boost and cmake to find local boost +installations via the standard cmake incantation:
+find_package(Boost 1.41.0 COMPONENTS thread iostreams)
+These driver files should be the same from release to release.
+This variable allows modification of this location; If this is a full +path, it will be used directly, otherwise it will be interpreted +relative to ${CMAKE_INSTALL_PREFIX}.
+This is the path in the build tree to the file that will contain +CMake exported targets, by default it is:
+${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/Exports.cmake
+See Tricks for Building against Boost with CMake for information on how to use this handy +file when building against an uninstalled boost. This variable +has no effect on installation, and is only useful if building separate +cmake projects against an uninstalled boost.
+If this is a full path, it will be used directly, otherwise it will be +interpreted relative to ${CMAKE_BINARY_DIR}.
+This is the path to which exported targest will be installed. By +default it is ${BOOST_LIB_INSTALL_DIR}. This must be a +relative path.
+See Tricks for Building against Boost with CMake for information on how to use this handy +file to build against an installed boost.
+Footnotes
+| [1] | See also the cmake docs for find_package(). |
Again, innumerable tiny tweaks.
+This is the first cmake beta based on upstream Boost_1_41_0_beta1. +There are way too many enhancements to mention.
+(1.41.0.cmakebeta1 and 2 omitted)
+This release (as released by upstream Boost) does not contain +CMake support. See above for independenly released CMake versions.
+Backport features from 1.41.0.cmakebeta3
+Skipped
+From the boost-cmake list:
+> As of now, your Boost 1.40.0 branch builds and installs without error
+> for me on Windows (Intel 11.1, Visual Studio 2009, Visual Studio 2010
+> Beta 1), Linux (GCC 4.2, GCC 4.4, Intel 11.1), and Mac OS X 10.6 (GCC
+> 4.2, Intel 11.1).
+This version also includes fixes for cmake version 2.8 (as of this +writing, in beta).
+Special thanks in alphabetical order:
+This version works on windows with MSVC and linux with gcc.
+This version is broken in the svn distribution. See later +releases with the .cmakeN suffix.
+Warning
+-DCMAKE_IS_EXPERIMENTAL=ORLY_YARLY
+This guard variable is included in releases of Boost.CMake through +version 1.38. You just need to set this variable to some value (be +creative) when running cmake for the first time to disable the +guard.
+Boost.CMake was included as an experimental system for the first time. +It is perfectly capable of doing the basic build and install of boost. +You must pass the argument
+-DCMAKE_IS_EXPERIMENTAL=ORLY
+to the initial run of cmake, or you will see an intimidating message +explaining that Boost.CMake != Boost.Build. It looks like this:
+-- ##########################################################################
+--
+-- Only Boost.Build is officially supported.
+--
+-- This is not Boost.Build.
+--
+-- This is an alternate, cmake-based build system that is currently under development.
+-- To try it out, invoke CMake with the argument
+-- -DCMAKE_IS_EXPERIMENTAL=YES_I_KNOW
+-- Or use the gui to set the variable CMAKE_IS_EXPERIMENTAL to some value.
+-- This will only be necessary the first time.
+--
+-- For more information on boost-cmake see the wiki:
+-- https://svn.boost.org/trac/boost/wiki/CMake
+--
+-- Subscribe to the mailing list:
+-- http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
+--
+-- NOTE: Please ask questions about this build system on the boost-cmake list,
+-- not on other boost lists.
+--
+-- And/or check the archives:
+-- http://news.gmane.org/gmane.comp.lib.boost.cmake
+--
+-- ##########################################################################
+CMake Error at CMakeLists.txt:61 (message):
+ Magic variable CMAKE_IS_EXPERIMENTAL unset.
+
+
+-- Configuring incomplete, errors occurred!
+Again, f you see this, just set that guard variable to something, to +demonstrate your tenacity and dedication. Then things will work fine.
+Quick and dirty HOWTO
+% mkdir /tmp/boost
+% cd /tmp/boost
+% svn co https://svn.boost.org/svn/boost/tags/release/Boost_1_38_0 src
+% mkdir build
+% cd build
+% cmake -DCMAKE_IS_EXPERIMENTAL=ORLY -DCMAKE_INSTALL_PREFIX=/path/to/installdir ../src
+At this point, you have two options: you either want to leave boost in +place and use it there, or you want to install it to a particular +location.
+In-place
+++If you’re competent to specify header/library paths +yourself and want to build in place:
++% make+and your libraries will be in /tmp/boost/build/lib, and the headers in +/tmp/boost/src, (where you’d expect them to be).
+
Installed to some location
+++This will install boost to lib/ and include/ under the +CMAKE_INSTALL_PREFIX given above:
++% make modularize # shuffles some headers around +% make install+
Warning
+In versions 1.38 and 1.39, if you want to make install, you +must make modularize first. This is an intermediate step +that we expect to go away in future versions.
+Also note that cmake supports DESTDIR for making .deb and .rpm +packages; see the standard cmake documentation
+There was a CMake branch that built these releases, but Boost.CMake +was not included in the official distribution.
+This page describes how to configure and build Boost with CMake. By +following these instructions, you should be able to get CMake, +configure a Boost build tree to your liking with CMake, and then +build, install, and package Boost libraries.
+You can get it here: http://www.cmake.org/HTML/Download.html
+There are precompiled binaries for CMake on several different +platforms. The installation of these pre-compiled binaries is mostly +self-explanatory. If you need to build your own copy of CMake, please +see the CMake installation instructions.
+Note
+In these instructions, we will do things such that the Boost source +tree (with CMake build files) is available in the directory +$BOOST/src and that the build will happen in $BOOST/build:
+$BOOST/
+ src/ # (source checked out to here)
+ build/ # (build output here)
+Note that it is not actually necessary to set any environment +variable BOOST, this is a convention used in this document.
+Tarballs and zipfiles are avaiable at +http://sodium.resophonic.com/boost-cmake in subdirectory 1.41.0.cmake0.
+Boost.CMake is distributed separately from upstream boost. Code is +in a git repository at +http://gitorious.org/boost/cmake.git. These documents correspond to +tag 1.41.0.cmake0. You can clone the repository locally and then check out +the tag:
+git clone git://gitorious.org/boost/cmake.git src
+cd src
+git checkout <TAG>
+where <TAG> is 1.41.0.cmake0
+Create and change to the directory that will hold the binaries that +CMake build:
+mkdir $BOOST/build
+cd $BOOST/build
+Run the CMake configuration program, providing it with the Boost +source directory:
+cmake -DCMAKE_INSTALL_PREFIX=/somewhere $BOOST/src
+(CMAKE_INSTALL_PREFIX defaults to /usr/local on unix and +C:\\Program Files\Boost on windows). Replace /somewhere above +with a path you like if the defaults aren’t okay. You’ll see output +from cmake. It looks somewhat like this:
+-- Check for working C compiler: /usr/bin/gcc
+-- Check for working C compiler: /usr/bin/gcc -- works
+-- Check size of void*
+-- Check size of void* - done
+-- Check for working CXX compiler: /usr/bin/c++
+-- Check for working CXX compiler: /usr/bin/c++ -- works
+-- Scanning subdirectories:
+-- + io
+-- + any
+-- + crc
+-- + mpl
+
+ (etc, etc)
+
+-- + program_options
+-- + ptr_container
+-- + type_traits
+-- Configuring done
+-- Generating done
+-- Build files have been written to: $BOOST/build
+The directory $BOOST/build should now contain a bunch of generated +files, including a top level Makefile, something like this:
+% ls
+CMakeCache.txt CPackConfig.cmake Makefile
+cmake_install.cmake libs/ CMakeFiles/
+CPackSourceConfig.cmake bin/ lib/
+Now build and install boost:
+make install
+You’ll see:
+Scanning dependencies of target boost_date_time-mt-shared
+[ 0%] Building CXX object libs/date_time/src/CMakeFiles/boost_date_time-mt-shared.dir/gregorian/greg_month.cpp.o
+[ 0%] Building CXX object libs/date_time/src/CMakeFiles/boost_date_time-mt-shared.dir/gregorian/greg_weekday.cpp.o
+[ 1%] Building CXX object libs/date_time/src/CMakeFiles/boost_date_time-mt-shared.dir/gregorian/date_generators.cpp.o
+Linking CXX shared library ../../../lib/libboost_date_time-mt.so
+[ 1%] Built target boost_date_time-mt-shared
+
+(etc etc)
+
+[100%] Built bcp
+
+(etc etc)
+
+-- Installing: /tmp/flanboost/lib/libboost_wave-mt-d.a
+-- Installing: /tmp/flanboost/lib/libboost_wave-mt-d.so
+-- Removed runtime path from "/tmp/flanboost/lib/libboost_wave-mt-d.so"
+-- Installing: /tmp/flanboost/bin/bcp
+-- Installing: /tmp/flanboost/bin/inspect
+And you’re done. Once the build completes (which make take a while, if +you are building all of the Boost libraries), the Boost libraries will +be in a predictable layout under the directory passed to +CMAKE_INSTALL_PREFIX (default /usr/local)
+There are two different sets of directions: visual studio, which is +quite specific, and nmake, which is much like the Unix version, above.
+Run CMake by selecting it from the Start menu.
+Use the Browse... button next to Where is the source code to +point CMake at the Boost source code in $BOOST\src.
+Use the second Browse... button to next to Where to build the +binaries to select the directory where Boost will build binaries, +$BOOST\build.
+Click Configure a first time to configure Boost, which will search +for various libraries on your system and prepare the build. CMake +will ask you what kind of project files or make files to build. If +you’re using Microsoft Visual Studio, select the appropriate version +to generate project files. Otherwise, you can use Borland’s make +files. If you’re using NMake, see the next section.
+On an XP box with VS9 one sees roughly this in the output window at +the bottom:
+Check for working C compiler: cl
+Check for working C compiler: cl -- works
+Detecting C compiler ABI info
+Detecting C compiler ABI info - done
+Check for working CXX compiler: cl
+Check for working CXX compiler: cl -- works
+Detecting CXX compiler ABI info
+Detecting CXX compiler ABI info - done
+Boost version 1.41.0
+Found PythonInterp: C:/Python26/python.exe
+Found PythonLibs: C:/Python26/libs/python26.lib
+Boost compiler: msvc
+Boost toolset: vc90
+Boost platform: windows
+Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
+Build name: msvc-9.0-windows
+ + preprocessor
+ + concept_check
+ ...
+ + units
+ + wave
+Configuring done
+The messages about ‘missing doxygen’ and whatnot are not +showstoppers for now, so long as configuration is successful. You +will be given the opportunity to tune build options in the CMake GUI +(see Configuring the buildspace for more detail). They will +initially appear red. Click Configure again when you are done +editing them. The one thing that you may wish to configure as part +of this ‘quickstart’ is CMAKE_INSTALL_PREFIX.
+Finally, click Generate to generate project files. Boost.sln, +the VS solution file, will appear in the where to build the +binaries directory from the cmake gui.
+Start a Visual Studio Command Prompt from the start menu. This +will spawn a command prompt window with certain env variables set. +CMake will detect these and automatically choose to generate NMake +files.
+cd to $BOOST/build and execute:
+cmake ..\src
+You will see output very similar to that on unix, see +Configure.
++Start up Visual Studio, load the solution or project Boost from +the Boost build directory you set in the CMake configuration +earlier. Then, just click Build to build all of Boost.+
+Execute nmake from the command prompt in the build directory.+
The installation of Boost’s headers and compiled libraries uses the +same tools as building the library. With Microsoft Visual Studio, just +load the Boost solution or project and build the ‘INSTALL’ target to +perform the installation. With NMake, nmake install.
+Adds an executable to the build
+| Parameters: |
|
+
|---|
where exename is the name of the executable (e.g., “wave”). source1, +source2, etc. are the source files used to build the executable, e.g., +cpp.cpp. If no source files are provided, “exename.cpp” will be +used.
+This macro has a variety of options that affect its behavior. In +several cases, we use the placeholder “feature” in the option name +to indicate that there are actually several different kinds of +options, each referring to a different build feature, e.g., shared +libraries, multi-threaded, debug build, etc. For a complete listing +of these features, please refer to the CMakeLists.txt file in the +root of the Boost distribution, which defines the set of features +that will be used to build Boost libraries by default.
+The options that affect this macro’s behavior are:
+Example
+boost_add_executable(wave cpp.cpp
+ DEPENDS boost_wave boost_program_options
+ boost_filesystem
+ boost_serialization
+ )
+Where Defined
+This macro is defined in the Boost Core module in +tools/build/CMake/BoostCore.cmake
+Note
+This is only needed in the presence of ‘modularization’ +which is currently disabled.
+Add additional include directories based on the dependencies of the +library being tested ‘libname’ and all of its dependencies.
+| Parameters: |
|
+
|---|
libname
++the name of the boost library being tested. (signals)+
BOOST_DEPENDS
++The list of the extra boost libraries that the test suite will +depend on. You do NOT have to list those libraries already listed +by the module.cmake file as these will be used.+
Example
+The following invocation of the boost_additional_test_dependencies +macro is taken from the signals library.
+boost_additional_test_dependencies(signals BOOST_DEPENDS test optional)
+Where Defined
+This macro is defined in the Boost Testing module in +tools/build/CMake/BoostTesting.cmake
+This macro creates a new Boost library target that generates a compiled library +(.a, .lib, .dll, .so, etc) from source files. This routine will +actually build several different variants of the same library, with +different compilation options, as determined by the set of “default” +library variants.
+| Parameters: |
|
+
|---|
where libname is the name of Boost library binary (e.g., +“boost_regex”) and source1, source2, etc. are the source files used +to build the library, e.g., cregex.cpp.
+This macro has a variety of options that affect its behavior. In +several cases, we use the placeholder “feature” in the option name +to indicate that there are actually several different kinds of +options, each referring to a different build feature, e.g., shared +libraries, multi-threaded, debug build, etc. For a complete listing +of these features, see Build Variants and Features.
+The options that affect this macro’s behavior are:
++Provides additional compilation flags that will be +used when building all variants of the library. For example, one +might want to add "-DBOOST_SIGNALS_NO_LIB=1" through this option +(which turns off auto-linking for the Signals library while +building it).+
+Provides additional compilation flags that +will be used only when building variants of the library that +include the given feature. For example, +MULTI_THREADED_COMPILE_FLAGS are additional flags that will be +used when building a multi-threaded variant, while +SHARED_COMPILE_FLAGS will be used when building a shared library +(as opposed to a static library).+
+Provides additional flags that will be passed to the +linker when linking each variant of the library. This option +should not be used to link in additional libraries; see LINK_LIBS +and DEPENDS.+
+Provides additional flags that will be passed +to the linker when building variants of the library that contain a +specific feature, e.g., MULTI_THREADED_LINK_FLAGS. This option +should not be used to link in additional libraries; see +feature_LINK_LIBS.+
+Provides additional libraries against which each of the +library variants will be linked. For example, one might provide +“expat” as options to LINK_LIBS, to state that each of the library +variants will link against the expat library binary. Use LINK_LIBS +for libraries external to Boost; for Boost libraries, use DEPENDS.+
+Provides additional libraries for specific +variants of the library to link against. For example, +MULTI_THREADED_LINK_LIBS provides extra libraries to link into +multi-threaded variants of the library.+
+States that this Boost libraries depends on and links +against another Boost library. The arguments to DEPENDS should be +the unversioned name of the Boost library, such as +“boost_filesystem”. Like LINK_LIBS, this option states that all +variants of the library being built will link against the stated +libraries. Unlike LINK_LIBS, however, DEPENDS takes particular +library variants into account, always linking the variant of one +Boost library against the same variant of the other Boost +library. For example, if the boost_mpi_python library DEPENDS on +boost_python, multi-threaded variants of boost_mpi_python will +link against multi-threaded variants of boost_python.+
+States that the name of static library variants on +Unix need to be named differently from shared library +variants. This particular option should only be used in rare cases +where the static and shared library variants are incompatible, +such that linking against the shared library rather than the +static library will cause features. When this option is provided, +static libraries on Unix variants will have “-s” appended to their +names. We hope that this is a temporary solution. At +present, it is only used by the Test library.+
+This option states that, when building a shared library, +the shared library should be built as a module rather than a +normal shared library. Modules have special meaning an behavior on +some platforms, such as Mac OS X.+
+States that library variants containing a particular +feature should not be built. For example, passing +NO_SINGLE_THREADED suppresses generation of single-threaded +variants of this library.+
+Specifies that extra variants of this library +should be built, based on the features listed. Each “variant” is a +colon-separated list of features. For example, passing +EXTRA_VARIANTS “PYTHON_NODEBUG:PYTHON_DEBUG” +will result in the creation of an extra set of library variants, +some with the PYTHON_NODEBUG feature and some with the +PYTHON_DEBUG feature.+
Example
+The Boost.Thread library binary is built using the following +invocation of the boost_add_library macro. The options passed to the +macro indicate that CMake should define BOOST_THREAD_BUILD_DLL to 1 +when building shared libraries and BOOST_THREAD_BUILD_LIB to 1 when +building static libraries. The NO_SINGLE_THREADED option inhibits +creation of any single-threaded variants of the library (which +obviously would not make sense for a threading library!). The flags +needed to compile the multi-threaded variants are automatically +added.
+boost_add_library(
+ boost_thread
+ barrier.cpp condition.cpp exceptions.cpp mutex.cpp once.cpp
+ recursive_mutex.cpp thread.cpp tss_hooks.cpp tss_dll.cpp tss_pe.cpp
+ tss.cpp xtime.cpp
+ SHARED_COMPILE_FLAGS "-DBOOST_THREAD_BUILD_DLL=1"
+ STATIC_COMPILE_FLAGS "-DBOOST_THREAD_BUILD_LIB=1"
+ NO_SINGLE_THREADED
+)
+This example is from libs/thread/src/CMakeLists.txt.
+Where Defined
+This macro is defined in the Boost Core module in +tools/build/CMake/BoostCore.cmake.
+Define a boost library project.
+| Parameters: |
|
+
|---|
where libname is the name of the library (e.g., Python, +Filesystem), srcdir1, srcdir2, etc, are subdirectories containing +library sources (for Boost libraries that build actual library +binaries), and testdir1, testdir2, etc, are subdirectories +containing regression tests.
+DESCRIPTION provides a brief description of the library, which can +be used to summarize the behavior of the library for a user. AUTHORS +lists the authors of the library, while MAINTAINERS lists the active +maintainers. If MAINTAINERS is left empty, it is assumed that the +authors are still maintaining the library. Both authors and maintainers +should have their name followed by their current e-mail address in +angle brackets, with -at- instead of the at sign, e.g.,
+Douglas Gregor <doug.gregor -at- gmail.com>
+For libraries that have regression tests, and when testing is enabled +either by BUILD_TESTS containing the (lowercase) name of this +library or the string ALL, the generated makefiles/project files +will contain regression tests for this library.
+This option specifies directories containing examples. Examples are +just libraries/executables created with boost_add_library +and boost_add_executable, except they are only built if +the name of the current project is specified in BUILD_EXAMPLES.
+Currently unused.
+Example
+The Boost.Thread library uses the following invocation of the +boost_library_project macro, since it has both a compiled library +(built in the “src” subdirectory) and regression tests (listed in the +“test” subdirectory):
+boost_library_project(
+ Thread
+ SRCDIRS src
+ TESTDIRS test
+ DESCRIPTION "Portable threading"
+ AUTHORS "Anthony Williams <anthony -at- justsoftwaresolutions.co.uk">
+ )
+Where Defined
+This macro is defined in the Boost Core module in +tools/build/CMake/BoostCore.cmake
+FIXME
+FIXME
+FIXME
+FIXME
+FIXME
+FIXME
++ Please activate JavaScript to enable the search + functionality. +
++ From here you can search these documents. Enter your search + words into the box below and click "search". Note that the search + function will automatically search for all of the words. Pages + containing fewer words won't appear in the result list. +
+ + +Adding a Compiled Library to CMake
+Boost’s CMake-based build system provides regression testing via +CTest, which +comes as part of CMake. This regression testing system can be used by +Boost developers to test their libraries locally and also by testers +and users to submit regression tests to a CDash server, which +collects and reports regression-testing results from different +sites. This document assumes that the reader has already learned how +to build and configure Boost using CMake.
+The variable BUILD_TESTS is a comma-separated list of projects for +which testing will be enabled, e.g.:
+"accumulators;iostreams;variant"
+or the string "ALL" for all projects, or the string +"NONE" to disable testing.
+Warning
+if you pass this list from a unix shell, don’t forget to +enclose the whole thing in quotes or escape the +semicolons.
+If you re-run the CMake configuration for Boost with BUILD_TESTS +set to ALL, you will notice that configuration takes significantly +longer when we are building all of the regression tests. This is due +to the very large number of toplevel targets (thousands) that are +created. Until boost’s testing scheme is reorganized to reduce this +number, we anticipate that only testing nodes will want to test ALL, +whereas developers will want to test the library under development and +those that are dependent on it.
+Warning
+It is not recommended to set BUILD_TESTS to +"ALL" when using Visual Studio generators. A very +large number (thousands) of targets are generated and +this can bring VS to grinding halt. To run all tests, +choose the NMake generator, see Configuration for NMake.
+Be sure to re-configure CMake once you are done tweaking these +options, and generate makefiles or project files, as mentioned in +Quickstart.
+If you’re using a command-line configuration (nmake files, unix +makefiles) you can simplify this process by passing the value of +BUILD_TESTS on the command line, e.g.
+cmake ../src -DBUILD_TESTS="mpi;graph_parallel"
+Note
+In Visual Studio, you should be prompted by the gui to +reload the project. If you’re unlucky, you will be prompted a +thousand times to reload each individual solution. For this +reason, our current best recommendataion is to close and reopen the +project if you rebuild Boost.sln.
+Follow the same building process described in Quickstart. For +Unix users, don’t forget the -i option to make (ignore errors), +and also possibly -j 2 (or more) to run the build process in +parallel. Building all of the regression tests for the Boost libraries +can take a long time.
+make -j2 -i
+Note
+If you change Boost source files in a way that affects your +tests, you will need to rebuild to update the libraries and +test executables before moving on to the next step.
+Once regression tests have finished building,
+at a command prompt, cd to the Boost binary directory. Then, run +the command:
+ctest
+to execute all of the regression tests. The ctest executable comes +with cmake. On Unix platforms, this is the same place where ccmake +resides. On Windows platforms, it will be in C:\Program +Files\CMake X.Y\bin. The ctest program should produce output like the +following:
+Start processing tests
+Test project /Users/dgregor/Projects/boost-darwin
+ 1/ 22 Testing any-any_test Passed
+ 2/ 22 Testing any-any_to_ref_test Passed
+ 3/ 22 Testing function-lib_function_test Passed
+ 4/ 22 Testing function-function_n_test Passed
+ 5/ 22 Testing function-allocator_test Passed
+ 6/ 22 Testing function-stateless_test Passed
+ 7/ 22 Testing function-lambda_test Passed
+ 8/ 22 Testing function-function_test_fail1 ***Failed - supposed to fail
+ 9/ 22 Testing function-function_test_fail2 ***Failed - supposed to fail
+ 10/ 22 Testing function-function_30 Passed
+ 11/ 22 Testing function-function_arith_cxx98 Passed
+ 12/ 22 Testing function-function_arith_porta Passed
+ 13/ 22 Testing function-sum_avg_cxx98 Passed
+ 14/ 22 Testing function-sum_avg_portable Passed
+ 15/ 22 Testing function-mem_fun_cxx98 Passed
+ 16/ 22 Testing function-mem_fun_portable Passed
+ 17/ 22 Testing function-std_bind_cxx98 Passed
+ 18/ 22 Testing function-std_bind_portable Passed
+ 19/ 22 Testing function-function_ref_cxx98 Passed
+ 20/ 22 Testing function-function_ref_portabl Passed
+ 21/ 22 Testing function-contains_test Passed
+ 22/ 22 Testing function-contains2_test Passed
+
+100% tests passed, 0 tests failed out of 22
+Here, we have only enabled testing of the Boost.Any and Boost.Function +libraries, by setting BUILD_TESTS to any;function.
+Warning
+Again, This ctest step runs the tests without first +running a build. If you change a source file and run the +ctest step you will see that no build is invoked.
+To run just a subset of the tests, pass -R and a regular +expression to ctest (see the output of ctest --help-full). For +example, to run all of the Python tests, use:
+ctest -R python
+There is also a -E (exclude) option which does the inverse of -R. +ctest --help shows the full list of options.
+You will see a solution named RUN_TESTS. Build this to run the +tests. If you want to run them from the commandline, for some +projects you will have to use the -C flag to ctest to specify the +ctest configuration type (Debug or Release, typically).
+The testing subsystem adds toplevel targets to the build. On unix you +can see them in the output of make help. For example some of the +accumulators test targets look like this:
+% make help | grep accum
+... accumulators-tests-count
+... accumulators-tests-covariance
+... accumulators-tests-droppable
+... accumulators-tests-error_of
+... accumulators-tests-extended_p_square
+... accumulators-tests-extended_p_square_quantile
+Note that they are prefixed with the name of the project, a dash, and +‘tests’. Under visual studio you will see these targets in the +‘solution explorer’.
+Donated by kitware, it is here:
+ +Warning
+This needs updating for git
+The ctest command can be used by individual developers to test +local changes to their libraries. The same program can also be used to +build all of Boost, run its regression tests, and submit the results +to a central server where others can view them. Currently, regression +test results based on the CMake build system are displayed on the Dart +server at http://www.cdash.org/CDashPublic/index.php?project=Boost.
+To submit “experimental” results to the Dart server, configure a Boost +binary tree by following the configuration instructions in the section +Quickstart, and then enable regression testing via the +BOOST_TESTS=ALL option, as described above. At this point, don’t build +anything! We’ll let CTest do that work. You may want to customize some +of the advanced CMake options, such as SITE (to give your site +name), and MAKECOMMAND (which, for makefile targets, governs the +top-level make call when building Boost). Finally, go into the Boost +binary directory and execute:
+ctest -D Experimental
+CTest will then reconfigure Boost, build all of the Boost libraries +and regression tests, execute the regression tests, and submit the +results to the Dart dashboard at +http://www.cdash.org/CDashPublic/index.php?project=Boost. Results +submitted to the dashboard are usually browsable momentarily within a +minute or two.
+Here is a recommended setup.
+Create a directory ctest on your test drone containing +subdirectories for the branches you’ll be testing, in this case +release and trunk.
+boost/
+ ctest/
+ branches/
+ release/
+ continuous/
+ build/ <= run ctest here
+ src/ <= checkout to here
+ nightly/
+ build/ <= run ctest here
+ src/ <= checkout to here
+and check out source to the directories listed above. We’ll do the +release branch as an example:
+% cd boost/ctest/branches/release
+% svn co http://svn.boost.org/svn/boost/branches/release src
+#
+# lots of output
+#
+% mkdir continuous
+% cd continuous
+now configure your build, enabling testing. In this case I’ll also +use an alternate compiler, from Intel:
+% cmake ../src -DBUILD_TESTING=ON -DCMAKE_C_COMPILER=icc -DCMAKE_CXX_COMPILER=icpc
+-- The C compiler identification is Intel
+-- The CXX compiler identification is Intel
+-- Check for working C compiler: /opt/intel/Compiler/11.0/083/bin/intel64/icc
+-- Check for working C compiler: /opt/intel/Compiler/11.0/083/bin/intel64/icc -- works
+
+ (etc)
+
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /home/troy/Projects/boost/ctest/release/continuous/build
+Now run ctest -D Continuous in a loop:
+% while true
+while> do
+while> ctest -D Continuous
+while> sleep 600 # take it easy on the repository
+while> done
+ Site: zinc
+ Build name: intel-11.0-linux
+Create new tag: 20090514-2207 - Continuous
+Start processing tests
+Updating the repository
+ Updating the repository: /home/troy/Projects/boost/ctest/release/nightly/src
+ Use SVN repository type
+ Old revision of repository is: 53002
+ New revision of repository is: 53005
+ Gathering version information (one . per revision):
+
+ (etc)
+If you add -V or -VV you’ll get a little more feedback about what +is going on. On unix it is handy to do this via the utility screen.
+Todo
+Figure out how to do this on windows, encapsulate some of +this scripting. Just use the ctest builtin scripting +language.
+Nightly testing should run triggered by a cron job or by Windows Task +Scheduler or what-have-you. You will need,
+but not a checkout of boost. CTest will do the checkout, build, test +and submit on its own.
+Create a directory to run in. As in the previous section, we’ll use +boost/ctest/branches/release/nightly, which I’ll call $DIR. +The CTest script should look like the following (you can copy/paste +this into $DIR/CTestNightly.cmake
+execute_process(COMMAND /bin/pwd
+ OUTPUT_VARIABLE PWD
+ OUTPUT_STRIP_TRAILING_WHITESPACE)
+
+message(STATUS "Running nightly build in ${PWD}")
+
+set(CTEST_SOURCE_DIRECTORY ${PWD}/src)
+set(CTEST_BINARY_DIRECTORY ${PWD}/build)
+
+# what cmake command to use for configuring this dashboard
+set(CTEST_CMAKE_COMMAND "/usr/local/bin/cmake")
+set(CTEST_CTEST_COMMAND "/usr/local/bin/ctest")
+set(CTEST_CVS_COMMAND "svn")
+
+set(CTEST_CVS_CHECKOUT "${CTEST_CVS_COMMAND} co https://svn.boost.org/svn/boost/branches/release ${CTEST_SOURCE_DIRECTORY}")
+
+# which ctest command to use for running the dashboard
+set(CTEST_COMMAND
+ "${CTEST_CTEST_COMMAND} -VV -D Experimental -A ${PWD}/notes.txt -O ctest.log"
+ )
+
+
+
+####################################################################
+# The values in this section are optional you can either
+# have them or leave them commented out
+####################################################################
+
+# should ctest wipe the binary tree before running
+set(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)
+
+#
+# this is the initial cache to use for the binary tree, be careful to escape
+# any quotes inside of this string if you use it
+#
+# Yes you can pass cmake -DBUILD_WHATEVER=ON type options here.
+#
+set(CTEST_INITIAL_CACHE "
+
+CMAKE_CXX_COMPILER:STRING=/opt/intel/Compiler/11.0/083/bin/intel64/icpc
+CMAKE_C_COMPILER:STRING=/opt/intel/Compiler/11.0/083/bin/intel64/icc
+
+SITE:STRING=zinc
+MAKECOMMAND:STRING=make -i -j2
+DART_TESTING_TIMEOUT:STRING=30
+BUILD_TESTS:STRING=ALL
+BUILD_EXAMPLES:STRING=ALL
+CVSCOMMAND:FILEPATH=${CTEST_CVS_COMMAND}
+")
+You will need to customize several variables:
+Now you’ll create a “notes” file, call it notes.txt. This will be +visible from the dashboard. Add the output of, e.g:
+gcc --version
+uname -a
+and the contents of the CTestNightly.cmake itself. Example:
+**************** CMAKE DASHBOARD NOTES *****************
+
+Notes file for CMake Nightly Dashboard.
+
+This dashboard is being generated on an eight core, 64 bit
+Ubuntu 9.04 machine with an intel c++ compiler.
+
+
+Questions about this Dashboard should be directed to troy@resophonic.com
+
+Linux zinc 2.6.27-11-generic #1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux
+
+icpc (ICC) 11.0 20090318
+Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
+
+--------------- Script file ---------------
+
+(contents of CTestNightly.cmake)
+Now run (as a cronjob or at the command line):
+ctest -S CTestNightly.cmake
+if you want extra verbosity add a -VV flag. You’ll see something like the following:
++ /opt/local/bin/ctest -VV -S CMakeDashBoard.cmake
+* Extra verbosity turned on
+Reading Script: /Users/troy/ctest/boost/release/nightly/CMakeDashBoard.cmake
+Run cmake command: /opt/i3/ports/bin/cmake "/Users/troy/ctest/boost/release/nightly/src"
+-- The C compiler identification is GNU
+-- The CXX compiler identification is GNU
+-- Check for working C compiler: /usr/bin/gcc
+(etc)
+-- Configuring done
+-- Generating done
+-- Build files have been written to: /Users/troy/ctest/boost/release/nightly/build
+Run ctest command: /opt/i3/ports/bin/ctest -VV -D Nightly -A /Users/troy/ctest/boost/release/nightly/notes.txt -O ctest.log
+UpdateCTestConfiguration from :/Users/troy/ctest/boost/release/nightly/build/DartConfiguration.tcl
+Parse Config file:/Users/troy/ctest/boost/release/nightly/build/DartConfiguration.tcl
+ Site: silver
+ Build name: gcc-4.0.1-macos
+(etc, etc)
+You’ll see it configure again, run... and sooner or later you’ll see +your results on The Dashboard.
+