tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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
> "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:

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.



Home | Main Index | Thread Index | Old Index