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/