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: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-09-23 05:01:25

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? I fail to see the distinction you're trying to make between the two.

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

>>> 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".

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

___
Rob

(Sent from my portable computation engine)