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.