Re: C++20 and gcc12/10

[Greg Troxel <gdt%lexort.com@localhost>]

David Holland <dholland-pkgtech%netbsd.org@localhost> writes:

> However, lots of things marked c++20 build just fine with the gcc10 in
> -10, including fairly widely used stuff like poppler.
>
> Is it reasonable to commit
>
>   -USE_CXX_FEATURES=      c++20
>   +# gcc10's C++20 support seems to be adequate and since an explicit
>   +# requirement of C++20 requires building gcc12 on 10.x and elsewhere,
>   +# hold off on the stricter constraint for now.
>   +#USE_CXX_FEATURES=     c++20
>   +GCC_REQD+=             10
>
> in packages where it works? It's easy enough to put back the stronger
> constraint if the build stops working.

I don't think this is reasonable.  Two separate comments

1) The world seems to think it's ok for programs to depend on really
recent language versions.  They're wrong of course :-) This means that
we can either not update to those releasess, which isn't really
reasonable (and pkgsrc can't even stop a premature, undiscussed, update
to sqlite that makes it depend on tcl, so it doesn't seem rational to
even talk about avoiding c++20-requiring updates).

We currently have a split between "c++nn" and a bunch of features, which
I find not adequately documented and semantically messy.  I think it
needs cleaning up.  Really, c++nn should mean full support.  If we want
to have c++nn-lite and then a bunch of features, so that the union is
c++nn, that seems ok.   The problem is then that this split is a
pkgsrc-only thing, and the rest of the world just checks for a language
version.

I would be ok with encoding such a split and trying to use it, as a
combination of extending what we have and cleaning up the semantics.

2) NetBSD's release schedule has been and continues to be unreasonable,
given the backdrop of the world.  NetBSD 9 is getting to be no longer
usable in general.  I have said multiple times that we should have
releases that are betweeen 12 and 24 months apart, and i mean realiably
<= 24, not pretend to aim for 24 and achieve 36.

It's very straightforward to aim for 18, look at the previous
branch/release interval, and then take the last release date, add 18
months, subtract the previous interval, and branch then.  I think that
means branching a few months ago.  (It would be reasonable, if someone
is willing, to get gcc14 in current first, at least for most arches, as
history tells us that the biggest pain point for being old is about the
in-tree compiler.)

Also, with adequately fast releases, the desire to delay to get one more
thing in should be much less.

This won't fix your trouble with NetBSD 10, but it will mean it will
fade faster compared to how long people's trouble with NetBSD 9 are fading.