Boost logo

Boost :

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>> 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
> bump above that in the abundance of caution.
> This allows the removal of lots of workaround code:
> src/boost-trunk{master}$ ../kf5/
> 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:

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

The DigitalMars one didn't define
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,

so before revision 85272, so if it needed the macro, it was already broken.

> and maybe there are others as well).

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at