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

Subject: Re: [boost] Removing old config macro and increasing compiler requirements.
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-08-03 17:08:38

on Wed Jul 31 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:

> 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.

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