Re: [boost] [modularization] proposal and poll

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 
with dependencies.

> For example:
>
> https://github.com/boostorg/functional/blob/develop/meta/libraries.json
>
> 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 
itself.

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 
level structures.

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.

--
Bjørn