boost/build
2
0
Fork 0
mirror of https://github.com/boostorg/build.git synced 2026-02-17 01:32:12 +00:00
Code Issues Projects Releases Wiki Activity
Files
afe576bc08bcd79c19e968cef0829952d84beaa2
build/CMake/doc/cmake.qbk
Troy D. Straszheim d61f063e74 Last test commit. 
[SVN r52576]
2009-04-23 20:49:50 +00:00

692 lines
28 KiB
Plaintext
Raw Blame History

[article Boost.CMake
[quickbook 1.3]
[authors [Gregor, Douglas], [Straszheim, Troy] ]
[copyright 2007, 2008, 2009 Douglas Gregor, Troy Straszheim]
[purpose
Building boost with cmake
]
[id boost.cmake]
[dirname cmake]
[license
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
<ulink url="http://www.boost.org/LICENSE_1_0.txt">
http://www.boost.org/LICENSE_1_0.txt
</ulink>)
]
]
[section Configuring and Building Boost with CMake]
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.
[@http://www.cmake.org/HTML/Download.html Download CMake]
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 [@http://www.cmake.org/HTML/Install.html CMake installation
instructions]. 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]:
[pre
$BOOST/
src/ (source checked out to here)
build/ (build output here)
]
Note that it is *not* necessary to set any environment
variable =BOOST=, this is a convention used in this document.
[section Check out Boost-CMake]
To get a copy of Boost with the CMake build system, retrieve it from the [@http://needlink Boost Subversion repository] with the URL http://svn.boost.org/svn/boost/trunk].
On unix:
[pre
% mkdir $BOOST
% svn co http://svn.boost.org/svn/boost/trunk $BOOST/src
]
[endsect]
[section Configure the Boost source tree]
To discourage the casual developer from trying the CMake build system
before it is fully developed a "kill switch" has been added to the
CMake file that needs to be turned off or the CMake build system will
simply NOT work.
This is the makefile generation step, using `CMake`'s configuration
tool. This step differs depending on whether you are using CMake's GUI
on Microsoft Windows or whether you are using the command-line tools
provided on Unix.
[section On Windows]
Run CMake by selecting it from the Start menu.
* Use the ''Browse...'' button to point CMake at the Boost source
code in [^ $BOOST\src].
* Use the second ''Browse...'' button to select the directory where
Boost will build binaries, [^ $BOOST\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, generate NMake files, etc.
* Click ''Configure'' a first time to configure Boost, which will
search for various libraries on your system and prepare the build.
* You will then be given the opportunity to tune build options in
the CMake GUI (see also [@http://needlink CMakeBuildConfiguration]. These
options will affect what libraries are built and how. They will
initially appear red. Click ''Configure'' again when you are done
editing them.
* Finally, click ''OK'' to generate project files.
[endsect]
[section On Unix]
Create the directory that will hold the binaries that CMake build,
[pre mkdir $BOOST/build ]
Change into the build directory you have just created:
[pre cd $BOOST/build ]
Run the CMake configuration program, providing it with the Boost source directory:
[pre cmake $BOOST/src ]
You'll see output from `cmake`. It looks somewhat like this:
[pre
% cmake BOOST/src
-- 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:
[pre
% ls
CMakeCache.txt CPackConfig.cmake Makefile
cmake_install.cmake libs/ CMakeFiles/
CPackSourceConfig.cmake bin/ lib/
]
That's it! You've now configured your source tree and are ready to start building Boost.
[endsect]
[endsect]
[section Build Boost]
Like configuration, the way in which one builds Boost with CMake differs from one platform to another, depending on your platform and how you configured CMake. Either way, you'll be using the tools provided to you by your compiler or operating system vendor.
[section Microsoft Visual Studio]
If you have generated project files for Microsoft Visual Studio, you will need to start up Visual Studio to build Boost. Once Visual Studio has loaded, 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.
[endsect]
[section On Unix (and when using makefile variants on Microsoft Windows)]
The first thing to run is the "modularize" target.
[pre
make modularize
]
This will MOVE most of the headers and subdirectories from the BOOST/src/boost/boost into BOOST/src/boost/libs. This WILL in effect DISABLE the bjam build system until you 'revert' your svn repository.
The next step is to run the actual build.
One builds using standard "make" tools. In the directory BOOST/build (where the generated makefiles are) run `make`:
[pre
make
]
That's it! Once the build completes (which make take a while, if you are building all of the Boost libraries), the Boost libraries will be available in the `lib` subdirectory of your build directory, ready to be used, installed, or packaged.
[endsect]
[section Installing Boost]
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. Unix and makefile users will change into the Boost build directory and use the `install` make target, e.g.,
[pre
make install
]
[endsect]
[endsect]
[endsect]
[section Configuring the build]
[section Setting the compiler]
See '''''Advanced Options''''' below.
[endsect]
[section Configuration tools]
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. On unix, run
[pre
ccmake <path-to-source>
]
where `ccmake` will be in CMake's binary directory. If you have not yet run `cmake` in this directory,
you will see an empty list of options:
[pre
Page 0 of 1
EMPTY CACHE
EMPTY CACHE:
Press \[enter\] to edit option CMake Version 2.6 - patch 0
Press [c\] to configure
Press [h\] for help Press [q\] to quit without generating
Press [t\] to toggle advanced mode (Currently Off)
]
After pressing *c* to configure, (or if you've run [^ cmake] already),
You will be presented with a list of editable build options something like this:
[pre
BUILD_BOOST_DATE_TIME ON
BUILD_BOOST_FILESYSTEM ON
BUILD_BOOST_GRAPH ON
BUILD_BOOST_IOSTREAMS ON
BUILD_BOOST_PROGRAM_OPTIONS ON
BUILD_BOOST_PYTHON ON
BUILD_BOOST_REGEX ON
BUILD_BOOST_SERIALIZATION ON
BUILD_BOOST_SIGNALS ON
BUILD_BOOST_TEST ON
BUILD_BOOST_THREAD ON
BUILD_BOOST_WAVE ON
BUILD_BOOST_WSERIALIZATION ON
BUILD_DEBUG ON
BUILD_MULTI_THREADED ON
BUILD_RELEASE ON
BUILD_SHARED ON
BUILD_SINGLE_THREADED ON
BUILD_STATIC ON
BUILD_TESTING OFF
BUILD_VERSIONED ON
CMAKE_BACKWARDS_COMPATIBILITY 2.4
CMAKE_BUILD_TYPE
CMAKE_INSTALL_PREFIX /usr/local
DEBUG_COMPILE_FLAGS -g
EXECUTABLE_OUTPUT_PATH
LIBRARY_OUTPUT_PATH
PYTHON_EXECUTABLE /usr/bin/python2.4
PYTHON_INCLUDE_PATH /usr/include/python2.4
PYTHON_LIBRARY /usr/lib/python2.4/config/libpython2.4.so
RELEASE_COMPILE_FLAGS -O3 -DNDEBUG
BUILD_VERSIONED: Use versioned library names, e.g., boost_filesystem-gcc41-1_34
Press [enter\] to edit option CMake Version 2.4 - patch 5
Press [c\] to configure Press [g\] to generate and exit
Press [h\] for help Press [q\] to quit without generating
Press [t\] to toggle advanced mode (Currently Off)
]
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.
[endsect]
[section CMakeCache.txt]
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:
[pre
ccmake <path-to-build>
]
or have the makefiles do it for you:
[pre
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:
[pre
////
//// Enable/Disable color output during build.
////
CMAKE_COLOR_MAKEFILE:BOOL=ON
////
//// Use versioned library names, e.g., boost_filesystem-gcc41-1_34
////
BUILD_VERSIONED: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
[pre
make rebuild_cache
]
[section Useful options]
More detail on some of these options is available elsewhere. But here is a summary:
[table Options
[[Name][Description]]
[[=BUILD_VERSIONED=] [Toggles mangling of compiler name and boost version into library names]]
[[=BUILD_TESTING= ] [Toggles build of testing]]
[[[^ BUILD\_BOOST\_]/library/][Toggles building and testing of [~ library] (e.g. this will appear as [^ BUILD_BOOST_REGEX], [^ BUILD_BOOST_PROGRAM_OPTIONS], etc.)]]
[[=BUILD_=/feature/] [Toggles build of feature /feature/, where /feature/ comes from the list found at *needlink*,
e.g. [^BUILD_RELEASE], [^BUILD_DEBUG], [^BUILD_MULTI_THREADED], etc.]]
[[=TEST_BOOST_=/library/][Toggles testing of /library/ (this option appears only if [^ BUILD_BOOST_]/library/ and [^ BUILD_TESTING] are enabled. See *needlink*)]]
[[[^ CMAKE_OSX_ARCHITECTURES]][ /Mac OS X users/: to build universal binaries, set this to [^ ppc;i386].]]
]
[^ ccmake] provides the keystroke option [^ t] which toggles advanced mode. Some of the useful options here are:
[table Advanced options
[[Option][Description]]
[[=CMAKE_VERBOSE_MAKEFILE=] [Displays full build commands during build. Good for debugging. Advanced option: use [^ t] to toggle display of this option and others. On unix, you can also build verbose by passing the command line option VERBOSE=1 to your [^ make] invocation.]]
[[=CMAKE_CXX_COMPILER=] [Sets the compiler.]]
]
[endsect]
[endsect]
[endsect]
[section Building individual libraries with cmake]
In a configured cmake workspace, `make help` will display a list of available targets. Example:
[pre
% 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:
[pre
% 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
]
[section Preprocessing]
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:
[pre
% 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:
[pre
% 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:
[pre
% 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
]
[endsect]
[endsect]
[section Adding a Boost Library with CMake]
This page describes how to introduce a new Boost library 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] macro, which
identifies each Boost library to the build system. The invocation of
the [^ boost_library_project] will look like this:
[pre
boost_library_project(
Libname
SRCDIRS src
TESTDIRS 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 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
get CMake building and installing your library.
If your library has regression tests (it ['does] have regression
tests, right?), follow the instructions on adding regression tests
to get CMake to build and run regression tests for your library.
[endsect]
[section Adding a Compiled Library to CMake]
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 *needlink* adding a library to CMake, so that the
CMake system recognizes your Boost library.
In this page, 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
[@http://needlink boost_library_project macro], as described
in the previous section, [@http://needlink "Adding a Library
to CMake"]. 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 [@http://needlink boost_add_library macro], which adds a
compiled Boost library to the CMake system. The `boost_add_library`
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:
[pre
boost_add_library(boost_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.
[section Compilation Flags]
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`:
[pre
boost_add_library(boost_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.,
[pre
boost_add_library(boost_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
[@http://needlink boost_add_library macro reference] for more
information.
[endsect]
[section Linking to Other Boost Libraries]
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 [@http://needlink
boost_add_library macro] to state which libraries our library depends
on. In this example, we'll link against `boost_filesystem`:
[pre
boost_add_library(boost_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.
[endsect]
[section Linking External Libraries/Optional Sources]
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:
[pre
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`:
[pre
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.,
[pre
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
[@http://needlink boost_add_library macro]. Using these features
together, we can search for the `PNG` library on the system and
optionally include PNG support into our library:
[pre
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(boost_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/CMake/Boost_1_35_0/tools/build/CMake/FindICU.cmake
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/CMake/Boost_1_35_0/libs/iostreams/src/CMakeLists.txt
libs/iostreams/src/CMakeLists.txt].
[endsect]
[section Build Variants]
The Boost build system defines many different [@http://needlink
build 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 [@http://needlink 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`:
[pre
boost_add_library(boost_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
]
[endsect]
[endsect]
Reference in New Issue View Git Blame Copy Permalink