Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-06-01 06:37:46

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

In general, of course we should not cut dependencies at all costs. From 
what you say I get the impression Boost.Math might actually be best off as 
a monolithical submodule.

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

I think what you describe here would be a good solution.

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

So far there seems to be quite some support for the general idea of 
dependency reduction and automated dependency cloning, so I'm willing 
to write a more detailed proposal that includes (as unintrusive as possible) 
policies for library maintainers when I find the time.

-Julian