Re: [boost] [modularization] What is a module? What is a sub-module?

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.

OK.

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

--
Bjørn