Re: [boost] A bike shed (any colour will do) on greener grass...

Subject: Re: [boost] A bike shed (any colour will do) on greener grass...
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-31 15:30:22

On 10/31/2013 07:21 PM, Niall Douglas wrote:
> On 31 Oct 2013 at 19:00, Stephen Kelly wrote:
>
>>> I am personally strongly in favour of libraries getting deprecated 
>>> and removed from releases if they are not maintained - let's say no 
>> [snip]
>> With 68 libraries in a circular-dependent mesh, how do you expect that
>> would work?
> Judging from that dependency graph you posted a while ago, you're 
> right there is a small core of libraries where deprecation due to 
> lack of maintenance can't work.

I don't consider 68 out of 104 to be 'a small core'.

Are you referring to the 11 packages that would remain interconnected
after all of my suggestions were implemented? Some of my suggestions
were implemented, but not all.

I would agree with calling that small, but no further work on
modularization is likely to be done. I'm not willing to do any such
horizontal work after the move to git, so someone else would have to
step up to do it.

I also have not analysed the graph again since the proto->spirit edge
removal, the property_map changes and Daniels commit to the migration
map, so the 68 and 104 may not reflect todays state, and I don't know
the effect that those changes in isolation had on the total graph.

> I suspect that core library list is far smaller than 68, but you're 
> the expert here. Do you know how tightly integrated those 68 
> libraries are e.g. 

> how many of them pull in a dependency only to 
> never use it or use it very lightly?

I never counted, but 'at least some and maybe several'. Where I
arbitrarily define some < several by an order of magnitude of 3 or so :).

>  How many pull in dependencies 
> which can now be replaced with C++11 standard libraries instead? That 
> sort of thing.

Probably less than 'some' above. I realise that that's meaningless
without some quantified baseline :).

Some users of the mpl are just using things like mpl::and_ and mpl::or_
etc, which can be implemented easily with a variadic template, thereby
avoiding Boost.PP for example.

Thanks,

Steve.