Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-05-29 17:16:52

On 29 May 2014 at 22:22, Julian Gonggrijp wrote:

> I would like to revive the topic of Boost inter-library dependencies,
> suggest two global changes to Boost and ask whether you agree with the
> course of action I propose.

Here goes the fun again. Glad I'm not the one starting a thread this 
time!

> I think there could be a less ambitious but faster way to provide
> automated dependency handling. It would take no more than some static
> configuration, to list for each library what other Boost libraries it
> depends on, combined with a simple script that automatically traverses
> the dependency graph and clones just the necessary submodules. This
> script may then be hooked into the bootstrap script. I think I could
> write the dependency handler, and I would be willing to, though I
> can't currently provide any indication of when I would be able to
> start.

If a fork of Boost becomes necessary later this year, I was thinking 
an accurate dependency graph could be generated by having the unit 
test CI reuse fabricate's (https://code.google.com/p/fabricate/) 
compiler file loading tracing implementation. That would fire the 
dependency graph into a future AFIO based graph store, and forked 
Boost would download the appropriate graph shard on demand into a 
local graphstore. That would enable easy per-library source distros, 
and other such goodies.

> However, even if we had an automated way to handle dependencies, that
> would not be a sufficient solution to true modularity. As has been
> discussed before, the interdependencies between Boost libraries are
> currently so strong, that even using a single header file may likely
> require the user to copy a substantial portion of Boost [2]. This is
> especially the case because there are many cyclical dependencies
> [3, 4].
> 
> Stephen Kelly investigated how the interdependencies between Boost
> libraries could be reduced, especially the cyclical dependencies. He
> concluded that most cyclical dependencies could be eliminated and that
> the dependency graph could be simplified substantially overall. He
> also described concrete ways to achieve this. [3 and onwards]

The hard part isn't what to do. The hard part is gaining community 
buy in when "their" code gets broken by the necessary changes. I have 
concluded it isn't possible, hence me proposing a fork where such 
"radical" changes won't upset anyone. Like the Python 3.x vs 2.x 
fork.

> I think it may be easier for the steering committee to justify any
> decision on this proposal, if they have hard statistics about the
> amount of support it receives. Therefore, I invite every opinionated
> person reading this to reply with a vote, either in favour of the
> proposal or against it. I invite you to do this even if you do not
> feel the need or find the time to provide arguments for your position.
> You can later re-vote if you change your mind.
> 
> I will count the votes, and when there are more than 30 I will start
> posting the statistics occasionally. Votes are public so everyone can
> verify my data when necessary. Anyone, including the steering
> committee, can then use the numbers however they choose.

Decisive and immediate action on this is vital if Boost is to 
survive. I vote yes to both, ASAP.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/