Subject: Re: [boost] [modularization] proposal and poll
From: BjÃ¸rn Roald (bjorn_at_[hidden])
Date: 2014-06-01 06:33:34
On 05/31/2014 04:22 PM, Daniel James wrote:
> On 31 May 2014 12:23, BjÃ¸rn Roald <bjorn_at_[hidden]> wrote:
>> ---- What is the relationship between modules and libraries? -----
>> A library has a maintainer individual or group and is maintained in a
>> separate repository from other libraries in Boost. A library may contain
>> many modules.
> We already have multiple libraries in a repository.
I see no reason to disallow multiple libraries in a repository. If those
libraries are related through a group of maintainers working well
together and the libraries cover the same problem domain, then it may be
more natural and simpler.
Splitting boost into multiple repositories has to do with foreseen
scaling issues for the overall boost effort. As long as those goals are
not obstructed by larger repositories there should be no problem.
Forcing such libraries or modules into their separate Git repository is
not meaningful. On the contrary, enforcing such a policy will either
lead to too many repositories which is a challenge for humans and
technology, or too few modules, which will make it very hard to deal
> For example:
> These metadata files are only in a few libraries at the moment, but
> dependency specification could possibly be added to them.
Interesting, I take it these are the modular version of the information
needed to produce the listing of Boost Libraries for the web site and
documentation. It certainly could be built upon.
> Although if
> it's going to be done for subsets of libraries, it would need to be in
> a separate file or files.
Yes, or they could just be structure elements in the same meta file
under each library entry. But I can see that may be undesirable if the
module metadata become lengthy or complex.
Could we think of it differently, that Library in the traditional Boost
conventions are just a form of module that may have relationship to any
number of other modules depending on it. Such modules may be part of
the Library as far as authorship and maintenance if there is a ownership
relation "owned-by", defined in the meta data of the dependent module.
It should be considered natural, but maybe not mandatory, that a module
is in the same repository as the module that it is owned-by. Thus e.g.:
a test module can have separately defined dependencies from the library
What we call the structures boost is organized into need to be agreed
and understood. From legacy, library is an obvious structure element.
Whether the modules that we should be thinking of when we attempt to
modularize boost are structured as libraries, units, components,
package, files, directories, repositories or some combination of these
is not clear. It make sense to have some constraints to what a module
can be if metadata need to be recorded and tools need to support higher
Whatever is decided, if something in addition to repository and library
need to be given a name. As of now, I suspect that what I think of as a
module in general terms, to others the same structure elements may be a
sub-library, a library support directory such as doc, example, test, or
a feature support file. They may not understand that I am thinking of
all of these as modules. Common terminology is not important as long as
we understand each other, but it makes understanding harder. To fix
that, it may help with a common set of defined terms.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk