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

On 09/23/2014 11:01 AM, Rob Stewart wrote:

On September 22, 2014 5:20:10 PM EDT, "Bjørn Roald" wrote:

...

On 09/22/2014 11:37 AM, Rob Stewart wrote:

...

On September 21, 2014 11:12:51 AM EDT, "Bjørn Roald" 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