Building Boost Libraries
Many of the Boost libraries are implemented entirely in their header files,
and so are ready to use without performing a library build.
For libraries which must be built before use, build scripts are provided for
a number of platforms and compilers. If there isn't yet a build script for
your platform or compiler, please consider creating one and submitting it for
inclusion in Boost.
Script |
Operating System |
Compiler |
win32-vc6 |
Windows |
Microsoft Visual C++ Version 6.0 |
win32-bc55 |
Windows |
Borland C++ Version 5.5 |
Script use
- Set up your compiler for command line compilations and links, if you
haven't done so already. Note that even though a compiler's integrated
development environment (IDE) is installed and working, addition preparation
may be required. May compilers require compiler specific environment
variables be set, and so compilers require special non-IDE binary
executables be installed.
- Using the command line interpreter, change to the "lib"
sub-directory within the unzipped Boost distribution directory structure.
- Execute the build script appropriate for your operating system and
compiler. On most systems, this is done by simply entering the name of
the script and hitting the enter key.
- Inspect the output, particularly the last step which executes a final
confidence test.
Script behavior
All scripts follow the same basic behavior:
- Check for presence of various programs and environment variables required
by later steps.
- Compile and link the booster.cpp tool used by later steps, if not already
present. This also verifies that the command line compiler and linker
are working correctly.
- Create a sub-directory as a target for the library builds, if not already
present. The sub-directory will have a name similar to the script name,
which identifies the particular platform and compiler. This allows for
building libraries for multiple compilers, operating systems, and boost
versions.
- Builds as many libraries as are commonly used for the compiler. For
example, six libraries are generated for one well-known compiler:
- Static Single-Threaded
- Static Single-Threaded Debug
- Static Multi-Threaded
- Static Multi-Treaded Debug
- Dynamic Multi-Threaded
- Dynamic Multi-Treaded Debug
- As a final confidence test, compiles, links, and executes a short program
which uses one of the boost libraries just built.
FAQ
Q. Can I build libraries for multiple compilers? A. Yes,
no problem. A separate sub-directory will be created for each.
Q. Can I build libraries for multiple Boost versions? A. Yes,
just be sure to install each version in a different root directory. All
directories and files created are relative to the current directory, so there is
no problem if other versions exist elsewhere.
Q. Can I build libraries for multiple OS's? A. Yes, but scripts
are only provided in the native scripting language for each platform. The
separate sub-directories will keep the various libraries separated and
identified.
Design
Design of a build system for Boost was unexpectedly difficult. Design
issues are documented here to preserve rationale.
Assumptions
The requirements are driven by several basic assumptions:
- There is no single Boost developer or test facility with access to or
knowledge of all the platforms and compilers Boost libraries are used with.
- Boost libraries are used across such a wide range of platforms and
compilers that almost no other assumptions can be made.
Requirements
- A developer adding a new library must at most add only a single entry to a text file, and not have to know anything about platform specific files. If possible, a newly added library should be automatically detected, so that the developer doesn't need to do anything at all beyond using the boost directory structure.
- A developer adding support for a new platform or compiler should only have to add to a single file describing how to do the build for that platform or compiler, and shouldn't have to identify the files that will need to be built.
- The build should rely only on tools native to the platform and compiler, or supplied via the boost download. (Thus ScCons isn't a solution, even if was available, because it requires Python be installed.)
- The details of how the build is done for a particular platform or compiler should be appropriate for that platform. Thus there might be a supplied make file, an IDE configuration file, or whatever suits.
- The requirements above imply some new automated tool. Jens Maurer's regression.cpp has shown that such a tool (with separate file and command configuration) can be kept very simple yet effective.
- Platform and compiler specific build files can and should be pre-generated and supplied as part of the download to minimize user effort.
- Some users wish to build libraries form multiple platforms or compilers. It is easier to supply all build files and let the user choose which to invoke.
- The build tools must be able to handle Boost growth issues such as identified in Directory Structure proposals and discussion.
(Thanks to John Maddock for private discussions regarding several of these requirements.)
© Copyright Beman Dawes, 2001
Revised 09 January, 2001