On 10/13/2013 12:11 PM, Joaquin M Lopez Munoz wrote:
Stephen Kelly
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.