| Home | Libraries | People | FAQ | More

# 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