Getting Started with Modularized Boost Library Development

This is a work in progress

Prerequisites

• An understanding of Boost culture and the Developer's mailing list. Read more.
• An understanding of Boost Library Requirements and Guidelines.
• The Git version control system. Read about Getting Started with Git. If you are new to Git, install it and experiment a bit before coming back here.
• A (free) ​GitHub account. Read about Getting Started with GitHub. If you are new to GitHub, be sure to do the exercise before coming back here.
• Your favorite compiler and development environment.
• A recent version of Boost installed.

Overview

• Your library has its own public repository 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.
• The Boost super project has its own public repository. It treats your library as a sub-module, i.e. a link to a particular release in your library's public GitHub repository.
• You (and the rest of your team) do day-to-day development using private repositories on your local machines. You push changes from these local private repos up to your library's public repo whenever you want. The local repos may also have private branches that are never pushed to the public repo.
• 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 Modularized 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   

Creating the simple library