Modular Boost Overview

This page gives an overview of how modular Boost is organized.

Overall Organization

Modular Boost consists of the Boost super-project and separate projects for each individual library in Boost. In terms of Git, the Boost super-project treats the individual libraries as sub-modules.

All public repositories are hosted at ​GitHub.

Releases of individual libraries occur asynchronously from releases of the Boost super-project.

Repositories

• The Boost super-project has its own ​public repository. It treats each individual library as a sub-module, i.e. a link to a particular release in the library's public GitHub repository. The super-project is maintained by the Boost release managers, and most library developers do not have write access.

• Each individual library has its own public repository. For example, Boost.Config has a ​public repository. The maintainer of a library decides who has write access to the public repository. Release managers and their helpers also have write access for administrative purposes.

• As with any Git repository, a library's developers do day-to-day work using private repositories on their local machines. When they push changes from these local private repositories up to the library's public repository is up to them, as is when the library issues releases. As usual with Git, the local repositories may have private branches that are never pushed to the public repository.

• Libraries are required to follow certain naming conventions for branches and directories, so that both humans and automatic test and management tools know where to find commonly referenced components. But beyond those requirements, each library is free to use whatever branch and directory strategies they wish.

Branches

To

• that has a "develop" branch for development work, and a "master" branch for your releases, which occur asynchronously from Boost releases. You may also have other branches, but that's up to you.
• You (and the rest of your team)
• Your library's directory structure conforms to Boost directory structure conventions, so both users and automatic processes can find header files, test files, build configurations, and the like. Beyond the conventions, your library's directory structure is up to you.

Directory Structure

For Modular Boost, header files are placed in a include/boost header hierarchy within your main directory. Here is what a very simple header-only library named simple would look like:

     simple
       include
         boost
           simple
             twice.hpp
       test
         twice_test.cpp
         Jamfile.v2
       index.html   

In other words, the directory structure of a library in boost-root/libs for modular Boost is the same as pre-modular Boost, except that it contains another sub-directory hierarchy, include/boost/..., where ... represents the library's directories and header files that previously lived in boost-root/boost. The effect of this change in directory structure is that the library is now entirely self-contained in a single directory and its sub-directories.

A real library would also have additional sub-directories such as doc, example, and src, as described in the directory conventions, but they are left out of simple for the sake of brevity.