Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-05-31 07:23:56

On 05/30/2014 01:17 PM, John Maddock wrote:
>
>
> On 30/05/2014 10:44, Andrey Semashev wrote:
>> On Thursday 29 May 2014 22:22:05 Julian Gonggrijp wrote:
>>>
>>> PROPOSAL
>>>
>>> The following (evolutionary) global changes to Boost should be planned
>>> and given priority over any other proposals [e.g. 5], in the following
>>> order:
>>>
>>> 1. Reduction of dependencies between Boost libraries.
>
> This is a worthy goal, I don't think anyone reasonably disagrees with this.

+1

>> Agree, to a reasonable point. I don't think that solid libraries
>> should be
>> torn apart or unrelated components of different libraries should be mixed
>> together just to reduce dependencies. The cases where this would be
>> beneficial
>> should be discussed with library maintainers.
>>
>> I think that notion of optional dependencies it also needed to achieve
>> this
>> goal. There are multiple places in Boost where dependencies are
>> intentionally
>> loosened but formally exist.
>
> Right the devil is in the detail.
>
> For example the Math lib is one of those with cyclic dependencies -
> there's a small core that a few libraries depend on, but which Math also
> uses to some degree (like lexical_cast).
>
> The question is:
>
> * How many sub libraries does it need to be split into?  FP
> classification is one, constants another, possibly rounding functions
> one more, then one more for everything else.  Grief.

I am not sure the Grief need to be so bad.  Are you assuming all modules 
have to be maintained in separate Git repositories?  That does not have 
to be the case.  I will try to explain better, i.e. with other words, 
what I have tried to say in past discussion on this topic.  I will use 
Boost.Math as an example, but this applies to any Boost Library, maybe 
in particular to Config which configure dependencies to a large number 
of technology dependent supporting features.  Those features can be seen 
as modules as well of you follow my line of though.

So, let us say Math repository is *not* split in any way but continue 
more or less as is, but is modularized somehow.  What could that look like:

First of all, everything that is supporting to the library itself such 
as tests, examples, docs, etc. are defined as separate modules. I think 
these already live in their separate sub-directories and have their 
separate build mechanics.  None of this incur dependencies in the Math 
Library modules themselves.

Then, everything in the library itself is split into modules based on 
some analysis of dependencies and re-engineering deemed needed to reduce 
those dependencies. The source and headers does not necessarily need to 
be moved around to make it explicit in the file structure of the 
repository.  That could be at the discretion of library maintainers. 
However, the library maintainer need to support some means for external 
tools to identify the content of the modules and their direct 
dependencies.  Such tools could then support various packaging and 
deployment needs.

The granularity of modules may vary a-lot.  Not accepting that will 
create problems. As example, there is some talk of optional headers in 
this discussion, in my mind that is simply a separate module. It is no 
need to require such single header modules to be moved into their own 
library, or to attempt to collect such headers with related dependencies 
into some common module.  That is just turning the problem around, mot 
really solving anything.

To understand where modularizing is going, and thus be able to answer 
the poll with less ambiguities. I think some fundamentals need to be 
agreed. Some issues in that regard is at least unclear to me, or I 
expect there to be other views than mine on the list if we where asked 
questions, like for example:

- What is a module?
- What is the relationship between modules and libraries?
- What is the relationship between modules and source repositories?
- When does a dependency between two modules occur?
- What sort of dependencies do we want to prevent occurring?

Intentions of those willing to proceed with work on modularizing boost 
is not clearly stated. References to past discussions are given, but no 
conclusions about how to proceed. I think that is intentional as some of 
the process may best be agreed to later.  However there is a danger of 
starting off in the wrong direction.  So maybe we should try to agree on 
some ground rules for modules in boost.

Below are my current notions of how the above questions should be 
answered.  I expect other to have other views.

----------- What is a module? -------------
A module can be a  single file or a collection of files (e.g.: header 
and source files) that are hard or impossible to use without the rest of 
the module.  A module is self contained, except that it may have defined 
dependencies to other modules incurring when it is used by a given tool-set.

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

---- What is the relationship between modules and repositories? -----
Repositories are used to maintain configuration control of a library or
some other set of modules in boost.  A repository may contain many modules.

---- When does a dependency between two modules occur?  -----
The dependency occur when a certain tool processing the dependent 
module uses or is attempting to use the module it is depending upon.  In 
the latter case we have a failure, which we clearly want to prevent, if 
that is not feasible, then failures should at least be simple to resolve 
by identifying the dependency and get it properly deployed onto the system.

---- What sort of dependencies do we want to prevent occurring?  ----
Dependencies to modules providing features the user is not requiring.
Dependencies to modules using technology the user is not utilizing.

-- 
Bjørn