Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: John Maddock (boost.regex_at_[hidden])
Date: 2014-05-30 07:17:18

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.

> 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.
* How can such a split be done and yet still provide a seemless 
experience for the user - i.e. I'm strongly in favour of keeping the 
docs all in one place, and the header directory structure as it is now, 
while possibly allowing users that are just using say lexical_cast to 
not have to download the whole Math lib.
* Ideally I'd like to keep maintenance overhead as low as possible - the 
change to the new Git directory structure has been quite disruptive, and 
everyone involved in maintaining the Math lib has got into "header hell" 
more than once by editing the wrong file.  Splitting the lib makes that 
even worse.

We also need sensible policies for dealing with optional components - a 
good example would be libraries that provide serialization support in a 
separate optional header.  The library as such does not require 
Boost.Serialization, but quite rightly the optional "bridging" support 
is there.  I asked about this last time this topic came up, but I saw no 
good answer?

Please note: *I still think reducing dependencies is a good idea*, but 
I'd really like to see some kind of workflow that addresses these 
issues, otherwise I fear actually making things worse if libraries get 
harder to maintain at the alter of reduced dependencies.

Regards, John.