-+
-+
-+ 
-+ 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. |
Building individual libraries with cmake
-+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
-+ICU (International Components for Unicode)
-+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
-+--
-+ICU (International Components for Unicode)
-+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.
-+