Re: pruning stale C language variants

David Holland <[email protected]> writes:

> According to the gcc14 man page, --std=c18 is a synonym for --std=c17,
> seemingly because even though everyone calls it the 2017 version it
> actually appeared in 2018. I don't see any reason we need to handle
> that.

I see these tokens as being in our namespace of languages, and I think
you are saying "we don't need to allow pkgsrc Makefiles to say c18
instead of c17".

>  > I propose to make this change post freeze.
>
> Seems reasonable.
>
>  > Also c2x should now be c23, I would think.  That requires adjusting all
>  > such USE_CC_FEATURES and FORCE_C_STD lines as part of renaming.   I
>  > propose to do this after freeze, if it seems not massive.
>
> Yes, it should be c23. I assume the same forces that brought us the
> fiasco called c23 are still at work, though, and at some point we'll
> need c2x back, or c3x, for the next round. But that can wait.

Agreed, but then it will mean something different, so it's good to purge
it now.

> There is one fly in this ointment, which is that we might need to feed
> c2x, c1x, or even c9x to older compilers. I'd expect that any needed
> support for this and c1x/c9x would already be in place; it might be
> necessary to extend that to provide c2x in place of c23 for some
> versions.

If so that is a pre-existing problem in the code.  Right now using these
random extra tags does not result in anything happening.  I think you're
suggesting

  if we're trying to add c23
    if our compiler is acme-old-version
       add --std=c2x
    else
       add --std=c23
    endif
  endif
  
and I have no objections to translating the "package needs c23" tag to
how some compiler wants to see it.  I think that's separable.