Boost logo

Boost :

Subject: Re: [boost] [modularization] What is a module? What is a sub-module?
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-09-23 12:54:28

On 09/23/2014 11:01 AM, Rob Stewart wrote:
> On September 22, 2014 5:20:10 PM EDT, "Bjørn Roald" <bjorn_at_[hidden]> wrote:
>> On 09/22/2014 11:37 AM, Rob Stewart wrote:
>>> On September 21, 2014 11:12:51 AM EDT, "Bjørn Roald"
>> <bjorn_at_[hidden]> wrote:
>>> What is a "main module"?
>> For library A, the main module live in
>> libs/A/include
>> libs/A/src
>> etc.
>> Each sub-library contain a module as well, sub.library A/x live in:
>> libs/A/x/include
>> libs/A/y/src
>> etc.
>> all these modules are modules of library A, but the main module is a
>> sort of focus point. It is the boost library's primary features. Sub
>> libraries are there to provide optional utilities that depend on or or
>> create a bridge to other modules, boost or external modules.
>> Sub-libraries could be used for other purposes than modularization,
>> e.g.
>> logical partitioning of a libraries facilities. But if that is useful,
>> it is off-topic, so I leave that.
> Did you notice how you switched from using "module" to using "library"
> in your discussion?

Why do you say that, I can not say I switched, at lieat not in that
direction. Further down I discuss if sublibraries should simply be
called modules.

> I fail to see the distinction you're trying to make between the two.

OK, first and most important. Library is an established boost term, I
do not want to suggesting anything fundamentally about that term. A
library contains one or more modules. If more than one module, then the
terms sub-module, sub-library have been used about these extra modules
in the modularization discussions. I suggested to call them
sub-library, and avoid calling them submodules due to probable confusion
with git submodule, but I think maybe it is better to simply call them
modules, and a Boost library may bave more than one of them to
facilitate modularization.

>>>> Repository:
>>>> A version controlled directory structure containing checked out or
>>>> modified files in a working directory and a database of the
>> repository
>>>> history and relationships to other repositories. In a git working
>>>> directory, the database is in the .git subdirectory or is pointed to
>> by
>>>> a .git file.
>>> The usual meaning of "repository", at least in my experience is the
>>> managed history in a certain control tool, not the files in a
>> workspace.
> That was supposed to be "version control tool", BTW.
>>>> Sub-Repository:
>>>> I suggest we do not use this term mean sub-library. Use the term
>>>> sub-library or git submodule instead.
>>> If the VCS ever changes again, the tool-specific name of this
>>> entity will probably change. It would be better to provide an
>>> abstraction. That is, formalize "subrepository" and not that a
>>> git submodule is a subrepository.
>> Good point. But, my take here was that we do not need the term
>> sub-repository, hence I don't really see the need for an abstraction
>> either. If the discussion is about VCS, we have git repository and git
>> submodule.

This is where my discussion og VCS terms ends...

> If the discussion is about source code structure and
>> organization we have libraries and modules. As stated above, maybe
>> sublibrary is not needed, we can simply use module.
> You say this isn't needed, but then you say if it is, use git
>terminology, while acknowledging that my suggestion of defining an
> abstract term is a good one. If this concept is needed, it should
> not be couched in git terminology, but rather in more generic VCS terms.

The concept I have in mind after the discussion above of VCS terms ends
does not have anything to do with VCS, that is what I am trying to say.
  I am suggesting we do not need abstractions for VCS terms.

>>>> Module:
>>>> A organized set of boost library code that can be handled in a
>> uniform
>>>> manner by boost tools. A module shall contain the include, test,
>>>> build,
>>>> and doc directory, Modules that are not header-only shall also
>> contain
>>>> the src directory that is used to build one or more corresponding
>>>> library files.
>>> How is a module distinct from a library?
>> A library can have more than one module. If it has one it is more or
>> less the same.
>>> Both are defined in terms of the directories they contain. Each is
>>> defined in terms of the other.
>> Module take 2:
>> A organized set of boost code that can be handled in a uniform
>> manner by boost tools. A module shall contain the include, test,
>> build, and doc directory, Modules that are not header-only shall also
>> contain the src directory that contain sources used to build static and
>> dynamic library files that the user will link with.
> I don't understand how that is distinct from "library".

A library may contain more than one module, if not modularization will
create new boost libraries needing maintainers, reviews, etc.

>>> I should think dependencies would be computed at the logical grouping
>>> represented by library or module, depending on what those terms
>>> actually mean.
>> Yes I do agree with that, I was just trying to point out some
>> addiitonal
>> potenital aspects. I was not saying we needed to care about them if
>> they are not needed. Module has that role as in modularization.
>>> I presume one will choose to build components by such logical
>> entities.
>> Maybe, but we need to define "component" and what that means if we are
>> going to use it. Actually to me, with regard to boost, component is
>> more or less synonym with module.
> I was using "component" in its usual sense while avoiding the terms
> you were trying to define. I wasn't necessarily trying to introduce
> it into the lexicon you're attempting to create.


When I have some time, I will draft an updated proposal.


Boost list run by bdawes at, gregod at, cpdaniel at, john at