[gdal-dev] RFC68: C++11 compilation mode - Call for vote on adoption

[Even Rouault]

Daniel,

> It's not clear to me that the benefits of the C++11 requirement justify
> the potential trouble for those who have to support platforms with older
> compilers.

I can understand your concerns, and I would personnaly have been fine with sticking with 
oldish C++ as well, but we must also take into account the appealing of the project 
environment to other developers for its long term viability.

> I do care about portability, it was one of the founding
> principles of the project 20 years ago and I do not think that "stick to
> GDAL 2.2" is an acceptable answer to the portability question. The fact
> that other SDKs or apps may have the C++11 requirement is also not a
> justification in my mind either for a core piece as important as GDAL.

If you look at Linux platforms that have not a default C++11-ready compiler (ie gcc < 4.8) and 
are still security maintained, I don't think there are that many. In Ubuntu world, 12.04 is no 
longer security maintained since April or May this year. And 14.04 old-LTS has GCC 4.8
Debian old-old-stable wheezy has gcc 4.7 but will be end-of-life May 2018, so when GDAL 
trunk will be released. Debian old-stable jessie has gcc 4.9, so it is fine.
RHEL/Centos 6 with gcc 4.4 and its super long support cycle is probably the only Linux distro 
that don't have the requirements out-of-the-box and still be security maintained at the time 
GDAL trunk is released.

Supporting old platforms means also supporting old versions of various dependencies. I do 
not really see a lot of funding coming for those activities, perhaps because people get it for 
free in all meaning of the term, like most maintainance tasks. If people really need to have 
recent GDAL on old platforms, they can use backported toolchains, hire developers to 
backport the features they need to older branches, etc...

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170908/d0127f1b/attachment.html>