[config] Removing support for old compilers: do we have a consensus yet?
Folks, As you know Boost.Config has had it's support for old compilers stripped out, and this is a controversial change. We're now at the point where I'd really like to get the routine changes/updates into release, but to do that we need a final decision on whether to keep (and release) Steven Kelly's changes in develop. So do we have a final decision? Thanks, John.
On 21 January 2014 18:51, John Maddock
Folks,
As you know Boost.Config has had it's support for old compilers stripped out, and this is a controversial change.
We're now at the point where I'd really like to get the routine changes/updates into release, but to do that we need a final decision on whether to keep (and release) Steven Kelly's changes in develop.
So do we have a final decision?
No. But, I favour reverting the changes to config. There are some people who care about this support, and even if that's a very small amount, that's a reason to keep the support in place. In contrast I can't really see any good reason for the changes (to *config*), the code they remove is code that never gets updated so there's no real maintenance benefit, it doesn't remove any dependencies. Of course this shouldn't stop other libraries from removing support for older compilers, and they may find it very beneficial to do so. I actually quite like the idea of creating a C++11 only Boost in the future, which will involve removing support much more aggressively, but also be a cleaner and more understandable break.
John Maddock wrote:
Folks,
As you know Boost.Config has had it's support for old compilers stripped out, and this is a controversial change.
We're now at the point where I'd really like to get the routine changes/updates into release, but to do that we need a final decision on whether to keep (and release) Steven Kelly's changes in develop.
So do we have a final decision?
I am in favor of removing support for compilers that don't support partial specialization, partial ordering and void returns, notably MSVC 6.0/7.0. Dropping support for GCC < 3 would probably be uncontroversial as well. Not sure about the others. I wonder however how this should be done. Just removing the macro definitions from the config compiler headers is not enough because people can in principle use their own configs. Might it perhaps be better to leave the compiler headers intact and just warn/#error in suffix.hpp when an unsupported macro is set?
I am in favor of removing support for compilers that don't support partial specialization, partial ordering and void returns, notably MSVC 6.0/7.0. Dropping support for GCC < 3 would probably be uncontroversial as well. Not sure about the others.
I wonder however how this should be done. Just removing the macro definitions from the config compiler headers is not enough because people can in principle use their own configs. Might it perhaps be better to leave the compiler headers intact and just warn/#error in suffix.hpp when an unsupported macro is set?
That actually sounds like a reasonable idea: it means we preserve the "accumulated knowledge" in the config headers (and that old stuff has absolutely zero impact on maintenance there, it's basically fossil code at this stage), while at the same time providing the user with a clear indication that they're doing something unsupported. Likewise library authors who really want to support those old compilers - or else just don't use any advanced features - can still do so. We can even provide a macro which when #defined suppresses the #error. Let me see if I can figure out how to revert those changes cleanly, John.
On 23/01/2014 05:49, Quoth John Maddock:
I wonder however how this should be done. Just removing the macro definitions from the config compiler headers is not enough because people can in principle use their own configs. Might it perhaps be better to leave the compiler headers intact and just warn/#error in suffix.hpp when an unsupported macro is set?
That actually sounds like a reasonable idea: it means we preserve the "accumulated knowledge" in the config headers (and that old stuff has absolutely zero impact on maintenance there, it's basically fossil code at this stage), while at the same time providing the user with a clear indication that they're doing something unsupported. Likewise library authors who really want to support those old compilers - or else just don't use any advanced features - can still do so. We can even provide a macro which when #defined suppresses the #error.
+1. It's better for the build to error out quickly with "you are using an unsupported compiler" (or even "your compiler does not support feature X, which is mandatory") than for it to fail in less obvious ways later (or worse, appear to compile successfully but then do something weird at runtime). So it makes sense for Config (or possibly Predef) to still detect all versions of compilers. And as you point out, it's nearly free and won't clutter the rest of Boost.
I am in favor of removing support for compilers that don't support partial specialization, partial ordering and void returns, notably MSVC 6.0/7.0.
For as little as my opinion may count, I would like to say that I strongly believe that hard-coding removal of support even for msvc-6 is wrong. If half of Boost or all of Boost does not work, then we can just let half of Boost or all of Boost not work ! No extra work for anyone. Maybe there are people out there using it and not reading this list. Maybe there are people who just irationally wish to use that compiler as I (apparently irationally) wish to use CodeGear's XE5 2 GB-download 6-GB installed size 1 hour-install made-in-2013-but-buggy-as-in-1998 2-or-3-or-4-times-faster-than-msvc-now-beat-that compiler. For it is written: "Thou shall love thy compiler.".
I wonder however how this should be done. Just removing the macro definitions from the config compiler headers is not enough because people can in principle use their own configs. Might it perhaps be better to leave
the compiler headers intact and just warn/#error in suffix.hpp when an unsupported macro is set?
I would like to kindly ask whether it is possible to define a (new) pre-processor symbol: BOOST_UNSUPPORTED_COMPILER and in a single new unsupported_compiler.hpp file (perhaps included by e.g. suffix.hpp => included by every file)... ... issue a warning message, an error message or a congratulation message based upon the new symbol. I am estimating that this might please everyone who wishes to see the "old" compilers failing every single library and also everyone who wishes to easily remove the hardcoded failure and still work with up-to-date Boost code (in order to drive themselves mad, if that is the desire of their hearts). Anyway, thank you ! (-:
On 1/21/2014 1:51 PM, John Maddock wrote:
Folks,
As you know Boost.Config has had it's support for old compilers stripped out, and this is a controversial change.
We're now at the point where I'd really like to get the routine changes/updates into release, but to do that we need a final decision on whether to keep (and release) Steven Kelly's changes in develop.
So do we have a final decision?
Are you asking just about changes in config or about all Boost libraries instead ?
As you know Boost.Config has had it's support for old compilers stripped out, and this is a controversial change.
We're now at the point where I'd really like to get the routine changes/updates into release, but to do that we need a final decision on whether to keep (and release) Steven Kelly's changes in develop.
So do we have a final decision?
Are you asking just about changes in config or about all Boost libraries instead ?
I'm asking specifically about config - as that effects all other libraries - and possibly user code as well. John.
On 1/22/2014 4:17 AM, John Maddock wrote:
As you know Boost.Config has had it's support for old compilers stripped out, and this is a controversial change.
We're now at the point where I'd really like to get the routine changes/updates into release, but to do that we need a final decision on whether to keep (and release) Steven Kelly's changes in develop.
So do we have a final decision?
Are you asking just about changes in config or about all Boost libraries instead ?
I'm asking specifically about config - as that effects all other libraries - and possibly user code as well.
I am personally for removing support for old compilers. My main argument is that the simplification in the code makes it easier to understand Boost source. This may be less so for Config, but is still important. I do not believe that Boost should have to support compilers which almost nobody uses anymore, which are not distributed by any major OSs anymore, and which are not supported by the companies/groups which created the compiler anymore. At some point the clarity and design of code suffers by having to create elaborate workarounds for C++ features which any decent compiler should support.
participants (6)
-
Adder -
Daniel James -
Edward Diener -
Gavin Lambert -
John Maddock -
Peter Dimov