Re: [boost] [modularization] proposal and poll

On 05/31/2014 04:22 PM, Daniel James wrote:

On 31 May 2014 12:23, Bjørn Roald 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