Re: [boost] Submodules of Boost libraries

Subject: Re: [boost] Submodules of Boost libraries
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-10-06 10:16:29

On Monday 06 October 2014 14:39:14 Mathias Gaunard wrote:
> On 29/09/14 20:48, Robert Ramey wrote:
> > Mathias Gaunard-2 wrote
> > 
> >> Hi folks,
> >> 
> >> I'd like to ready my library for inclusion into Boost.
> >> My library is made of several modules, and I'd like to keep that into
> >> Boost.
> >> 
> >> How does Boost handles multiple submodules within a library submodule?
> > 
> > I'm getting a little confused as to what we mean by module, library,
> > sub module, repository etc.
> 
> Boost is a set of libraries, which are managed by git submodules.
> 
> My own library is split in several functional modules, primarily because
> some of them have special dependencies and are optional.
> 
> How should this be presented for inclusion into Boost?

Currently, Boost is distributed as a monolithic source archive. Testers also 
check out all libraries before running tests. So with the current state of 
things it basically doesn't matter - you can do it in whatever way is more 
convenient for you. You may consider the following points though:

 - If the library consists of multiple git submodules, it takes longer to 
checkout. I've also seen GitHub timeouts when checking out some libraries (I 
think, GitHub will sometimes timeout ssh authentication, which is done for 
each submodule).
 - Multiple git sumbodules means separate git repositories for different parts 
of your library. This implies separate histories and inability of making 
synchronized changes to different repositories. Synchronized library releases 
can also be problematic.
 - AFAIK, there are no nested git submodules (i.e. submodules within 
submodules) in Boost. It's quite probable that they are not supported, and 
personally I'd prefer if we didn't nest git submodules.
 - A single git repository means that all your library sources will always be 
checked out together. This may be ok or not depending on how heavy your 
library is. However, it doesn't mean that all its components must be built 
together or that it should be considered as a single indivisible library. 
There is a notion of Boost sublibraries (which basically means multiple Boost 
libraries in the same git repo) which you could use.

I'll add that some people in this list are generating dependency reports 
between different libraries from time to time, and these reports are taking 
into account Boost sublibraries (i.e. you would see sublibs in the report and 
not git submodules). I've also started working on a prototype of a package 
management tool for Boost that will also take into account sublibs. There's no 
guarantee that sublibs will be the ultimate unit of distribution of the 
modular Boost though - it's all at a rather early stage.