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.
• 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.

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.
• Portions of your library's directory structure must conform to Boost conventions, so both users and automatic processes can find header files, test files, build configurations, and the like. Otherwise your library's directory structure is up to you.