Re: gdal 3.9.0, C++17, charconv, gcc7

[Patrick Welche <prlw1%welche.eu@localhost>]

On Fri, Jun 07, 2024 at 07:53:35AM +0200, Thomas Klausner wrote:
> On Thu, Jun 06, 2024 at 07:47:04PM -0400, Greg Troxel wrote:
> > We do, but we are in the strange situation where saying you need C++17
> > (because upstream says so) does not get you C++17, but some subset.  Not
> > only is this not documented, but the comments say that asking for a
> > language variant actually gets you that variant.
> > 
> > Besides having the documentation be accurate, there's a real mismatch
> > between the rest of the world which expects, naturally enough, "requires
> > C++17" to mean "a compiler that can compile all valid C++17 programs",
> > and pkgsrc, which means "a compiler that can compile some, except those
> > that can't, and we won't tell you which ones those are, and we don't
> > document what you need to ask for to make them all work".
> > 
> > I know that sounds cranky, but that's how I see at, coming from "read
> > upstream NEWS, set variables, and expect sound behavior".
> > 
> > Hence, I meant
> > 
> >   are we going to make C++17 means C++17
> > 
> > or
> > 
> >   are we going to document our Alice situation clearly, so that when
> >   someone reads C++17 in release notes, they can write
> > 
> >   USE_CXX_FEATURES= c++17 charconv other-secret-feature
> > 
> > instead?
> > 
> > 
> > Right now the straightforward approach leads to failing builds.
> > 
> > 
> > Maybe we should have c++17lite and map that as we do, but really to
> > commit something with that when upstream says c++17, one has to test
> > with the forced-by-c++17 version of each compiler, and no higher, and
> > that's basically impossible on NetBSD 10 or current.
> 
> I guess the way it is is because saying you need
> c++17-with-all-bells-and-whistles is impossible right now.
> 
> >From https://gcc.gnu.org/projects/cxx-status.html
> 
> "C++17 Support in GCC
> 
> GCC has almost full support for the previous revision of the C++ standard"
> 
> i.e. even now, c++17 support in gcc is not "complete".
>
> So c++17 support would need to pull in gcc14+ even if many c++17
> programs could build with gcc10.

I feel that that is an extreme reading. I would rather point to:

  https://en.cppreference.com/w/cpp/compiler_support/17

The charconv part appears as "Elementary string conversions" which
requires gcc 8 as opposed to 7 (without floating point which is
true for all the other compilers too). The other noticable library
feature is the file system library, which also requires gcc 8
according to that list.

I would suggest that we are unlikely to miss the library features
requiring gcc > 8. (e.g., if I were using parallel algorithms and
execution policies, I would ask for c++20)

I would just define c++17 as requiring gcc 8.

(BTW it still isn't clear to me what the difference between
USE_CXX_FEATURES and USE_CXX_FEATURES is. Either you need the
feature or you don't? (That is alwo where the secret feature
names are hidden ;-)
#       Valid values are: c++11, c++14, c++17, c++20, c++23, has_include,
#       regex, filesystem, unique_ptr, charconv, parallelism_ts,
#       put_time, is_trivially_copy_constructible.
))


Cheers,

Patrick