Boost logo

Boost :

Subject: Re: [boost] Removing support for old compilers
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-10-13 06:53:30

Le 13/10/13 12:11, Joaquin M Lopez Munoz a écrit :
> 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), 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, don't know about
> Borland, and maybe there are others as well). 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.
>> 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]
> As for where to put it, the final destination would be
> file boost_1_56_0.qbk
> although this file has not been created yet. You can either ask
> for the file to be created or, in the meantime, publish your log
> somewhere for easy reference and public access.
> 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])
+1. I think that every changes set should contain [library] text
> * 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.)
+1. Authors and maintainer should be notified before commit.
> * 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.
+1. These kind of changes could seem simple but the possibility to break
existing code is high.


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