Even Rouault <even.roua...@spatialys.com> writes: >> which is misplaced, because people are who merely intending to compile >> gdal but not contribute to it, still need to know. I almost didn't even >> look at it before writing that it wasn't documented which C++ flavor is >> needed, because it was obviously not about what I needed to know. > Attempt to improve in https://github.com/OSGeo/gdal/pull/10151
great, have commented. >> 2) NEWS for 3.9 does not mention that there is now a requirement for a C++17 >> compiler. > > ==> 3rd bullet point of "In a nutshell" > > * [RFC > > 98](https://gdal.org/development/rfc/rfc98_build_requirements_gdal_3_9.html): > Build requirements for GDAL 3.9 I see. I didn't find that searching for C++17.... For packagers reading, I would like to see * a C++17 compiler is now required not a link to some RFC, basically inlining what's new. Increased build requirements are a huge big deal, because they need to be encoded in packaging control files. Especially compilers, because on many systems, updating compilers is harder than updating geos along with gdal. >> 3) The person also marked gdal for c17 > > Can you be more explicit about you mean by "the person also marked > gdal for c17" : where exactly? In pkgsrc, we have checked in control files that decribe how to build each package. The gdal-lib package recently had a change to that file saying that the C compiler must support C17, and I am suspecting that requiring C17 is incorrect. It's not in RFC98 either. And you didn't say "oh yeah we need c17 now". gcc7, in NetBSD 9, supports almost all of c++17, but it seems that 100% support is not until gcc8. We may have an incorrect mapping c++17->7 when it should be 8. Specifically: Template argument deduction for class templates P0512R0 needs 8. So the big question is if gdal builds with gcc7, or if it needs 8. _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev