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
- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk