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
> 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
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 . 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
> 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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk