Re: C++20 and gcc12/10

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

Jonathan Perkin <jperkin%pkgsrc.org@localhost> writes:

>> > No, this belongs in infrastructure.  A package should only have to declare
>> > what it needs in terms of compiler support, not have OS-specific hacks
>> > spread across them.  Since adding support for *_FEATURES there shouldn't be
>> > any GCC_REQD in packages.
>>
>>Ahem. There's nothing OS-specific about "it works with gcc10".
>
> Well, you know what I mean.  The only reason this is being proposed is
> to work around an OS-specific issue, i.e. NetBSD's latest release
> shipping gcc10 and an aversion to using a more modern pkgsrc GCC.  If
> NetBSD 10 had shipped GCC 12 or newer then we probably wouldn't be
> having this discussion.

This is blurring motivation and architecture.  We are having the
discussion in the context of gcc10 in NetBSD 10 and not wanting to
unnecessarily drag in newer compilers because that's significant to many
on this list.  But it applies to every other slightly old system with
gcc10 in base.    If NetBSD were magically fixed, there would still be
RHEL N, and Ubuntu 22.04 (or whatever the right examples are).

> My point is that the way this works should be:
>
>  * Package simply declares "I need feature foo".
>
>  * Infrastructure determines whether foo is available natively, and if
>    not builds pkgsrc version to satisfy it.
>
>  * Any complicated logic to override this and have builtin satisfy foo
>    for whatever reason belongs in mk/platform.
>
> and that putting mk/platform stuff in packages, like is effectively
> being proposed here, is the wrong approach.

Agreed it doesn't belong in packages, but we're talking about how to
encode the need for subsets of language specs.

>> > [snip irrelevant]
>> >
>> > Also, if only specific parts of c++20 are required and they would be
>> > satisfied by GCC 10.x then they should be newly added to USE_CXX_FEATURES
>> > and handled appropriately.
>>
>>ok then, so what should the FEATURE be called? c++20-gcc10? c++20-lite?
>
> I mean like we already have for unique_ptr, regex, etc.  Whatever the
> part of c++20 is that the package needs that is supported by the GCC
> in NetBSD 10.

But this is catering to one version that you just said you didn't want
to do.   To me, these features  make sense when someone needs c++nn and
then a feature which is beyond NN.   To say you need NN and have that
mean "except for the parts that somehow have separate words" is
unreasonable.