
on Wed Jul 31 2013, Stephen Kelly
On 07/31/2013 03:32 PM, Paul A. Bristow wrote:
To catch people's attention, using an soon-to-be obsolete compiler or feature would have to produce an compile-fail error at first, but one that could be countermanded by users then making some macro definition meaning "I have read and understood the previous warning" so that it would compile.
This would loudly warn that this is the last version of Boost that will work, so they can either stick to that version, or upgrade compiler etc.
That could be an option. Timing is difficult though. I still believe, as I wrote before
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201/focus=2...
that modularization should be done before repo-splitting into many (35 in the case of attempting to use boost::any) interdependent repos.
Why do you believe that? It seems to me much, much easier to untangle undesired dependencies after the repositories are split.
For clarity for readers, the reply from Dave about KDE modularization seems to be referring to migrating from svn to git and the tool used for that, not kdelibs modularization. The svn to git migration happened several years ago, but the modularization of the existing kdelibs.git is a separate ongoing effort which will eventually result in multiple separate git repos. It is being done along with porting from Qt 4 to Qt 5:
http://community.kde.org/Frameworks/Epics
I know the migration from boost svn to multiple interdependent git repos will be done before 'actual' modularization, but I'd like to see what useful modularization steps can be done before that. I really really dislike git submodules, and I dislike working with more git submodules more :).
Git submodules are not part of the long-term plan, at least, not for most developers. The idea is that the ryppl tool prepares a workspace for you that includes all of the dependencies. The code surely doesn't work right now, but that's what we implemented in http://github.com/ryppl/ryppl, and I expect to ressurrect that work after the Boost SVN->Git transition is complete. -- Dave Abrahams