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. 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 :). Thanks, Steve.