Re: [boost] Removing old config macro and increasing compiler requirements.

Subject: Re: [boost] Removing old config macro and increasing compiler requirements.
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-07-31 09:53:37

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=208

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.