[gdal-dev] doc bugs about prereqs, surfaced by updating pkgsrc for 3.9

[Greg Troxel]

Even Rouault <even.rouault at 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.