Re: [boost] Removing support for old compilers

Subject: Re: [boost] Removing support for old compilers
From: Stephen Kelly (steveire_at_[hidden])
Date: 2013-10-13 06:28:32

On 10/13/2013 12:11 PM, Joaquin M Lopez Munoz wrote:
> Stephen Kelly <steveire <at> gmail.com> writes:
>
>> On 10/12/2013 10:13 PM, Joaquin M Lopez Munoz wrote:
>>> Hi Stephen
>>>
>>> As part of your initiative of removing support for old compilers,
>>> are you building somewhere a change log in the form of either a list
>>> of compiler deficiencies or compiler versions no longer supported?
>> I have not built such a thing, but it's easy to create by reading the
>> recent log of boost/config.
> Not obvious to me: the message log for your changes at boost/config
> reads
>
> * Remove remaining occurances of BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
>   These evaded scripting.
> * Require compiler support for partial template specialization.
>   Remove support for the mac programmers workshop entirely. Bump
>   the sunpro requirement to version 5.4. Version 5.3 seems to have
>   had some bugs with BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, so
>   bump above that in the abundance of caution.
>   This allows the removal of lots of workaround code:
>
>     src/boost-trunk{master}$ ../kf5/remove_def.py
>     BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
>     src/boost-trunk{master}$ git diff --shortstat
>      192 files changed, 4798 deletions(-)
> * Remove obsolete MSVC check from pragma guard
>   git grep -h -B1 "^#\s*pragma once" | grep -v pragma | sort | uniq
>   is now clean.
> * Config: Remove obsolete MSVC version check
>
> Frankly, it is hard to know what's going on by looking at this
> log alone. In particular, nowhere's stated which versions of
> MSVC have been dropped (I understand 6.0 and 7.0, but the log
> does not say it),

That was done in this commit actually:

 https://svn.boost.org/trac/boost/changeset/85272

That commit message doesn't specify the compiler versions affected
either though, indeed.

>  and one has to investigate in order to find out
> what other compilers are effecively dropped as a consequence of TPS
> being required (the log mentions MPW and SunPro 5.3, but I guess
> Digital Mars and GCC 2.x are also affected,

Only the config/compiler files for MPW and SunPro are affected by this
commit.

The DigitalMars one didn't define
BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, nor did it do so before
revision 85272, so if it needed the macro, it was already broken.

GCC 2.x is already no-longer-supported since revision 85272.

>  don't know about Borland, 

It didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, nor did it do
so before revision 85272, so if it needed the macro, it was already broken.

> and maybe there are others as well).

If they didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, they
were already broken.

>  I have also the suspicion
> that along the way you have removed macros and workarounds not
> directly related to TPS or MSVC 6.0/7.0. 

Can you be more specific?

>
>> Where should it be and what should it say?
> As for the form of the doc, something like this would be IMHO fine:
>
> * New minimal requirements on compilers/environments suported by
> Boost 1.56
>   - Template partial specialization support
>     · Deleted BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION and [etc]
>     from Boost.Config
>   - [Additional new requirements, SFINAE for instance]
>     · [Resulting changes in Boost.Config (macros removed and so on)]
> * Compilers dropped starting in Boost 1.56
>   - MSVC 7.0 and prior
>     · [Boost.Config facilities removed as a consequencce]
>   - GCC 2.x
>     · [Boost.Config facilities removed as a consequencce]
>   - [etc]
> * List of Boost libs directly modified [useful as a heads up for
> maintainers wishing to review your changes]

Looks good to me. I'll look into creating it.

> Some other things that'd help:
>
> * Consider adding some [xxx] subject tag in your communications to
> the mailing list so that users and maintainers can easily track
> them (for instance, [compiler support])

I'll never understand why people want '[compiler support]' prefixing a
message titled 'Removing support for old compilers' (both keywords are
there) or 'Bumping borland, SunPro, mwerks and MPW compiler
requirements' (MPW is more-specific than 'compiler support', so if
someone cares about MPW, that's what they'll notice).

Anyway, noted. I can't guarantee I'll remember or be able to force
myself to do it though.

> * Allow for some time for people to express support/dissent on proposed
> removals before going ahead, and notify the list when a change is
> effective. It is important that a proposed change comes with a list
> of compilers affected (users don't necessarily know whether some
> compiler X they care about does support, say, TPS, so we need to
> make sure this is clear to everybody potentially affected.)
> * With all due respect, I think you are being a little too aggresive
> at executing this. Removal of compiler support is a sensitive issue
> and sure enough we won't get unanimous consensus, but some form of
> general agreement should be reached, and time be given for awareness
> and discussion. That said, some assertiveness will be needed at the
> end of the day: it's a matter of finding the right balance and not
> going overboard with changes that could potentially harm existing
> Boost users. 

Ok, noted. Thanks for the feedback.

Steve.