Getting Started with Modularized Boost Library Development

This is a work in process

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

• The Boost repository itself treats your library as a sub-module, i.e. a link to a particular release in your library's public GitHub repository.
• Your library has a "master" branch for development work, and a "release" 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) do day-to-day development using private repositories on your local machines. You push changes from these local private repos up to the public repo whenever you want. The local repos may 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.

Header Directories

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

     foo
       include
         boost
           foo
             foo.hpp
       test
         foo_test.cpp
         Jamfile.v2
       index.html