Re: gcc.mk: adjusting charconv to follow the limited-versions guidance

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

Jonathan Perkin <jperkin%mnx.io@localhost> writes:

> Just for the record, I do not like the way that NetBSD-specific
> versioning is being hard-coded in a platform-agnostic file.  This may
> well be improving the situation on NetBSD, but making it worse on a
> different platform with different GCC versions in its base system (for
> example if it ships GCC 9 but now has a dependency on GCC 10 even
> though its native GCC 9 is absolutely fine).
>
> This kind of information should really be done in mk/platform, ideally
> with:
>
>  * gcc.mk containing the documented versions of when a particular
>    feature was added to GCC.

nit: documented and actually found to be true

>  * platform/OPSYS.mk overriding versions as necessary to accommodate
>    what is available on the platform.

I think what we need is a set of versions tuned for that platform, such
that the set is limited and aligned with that platform's releases/norms.
And then to round up to a set member, so that the GCC_REQD mechanism
only picks a member of that set (or a version higher than any member).

> This isn't an objection to your patch specifically, given that it just
> follows what is already in place, but I would like what is in place to
> be done properly at some point.

Thanks for splitting that hair; that was indeed my point.  I agree that
this should be improved.

I suspect that for someone good at writing make, defining
PLATFORM_GCC_VERSIONS to eg. "7 10 12" for some platforms, having a ?=
to something in case it isn't defined, and then the round-up code is not
that hard.  Really only the round-up code is perhaps tricky.

I will be glad to start setting these back to the right values if
someone implements the mechanism.  I've tried hard to add comments
documenting the right values as I go along.


The other thing we should perhaps grapple with is the idea that a
program can ask for c++17 and get a compiler that will not build all
valid c++17 programs, because there are split features for things that
are part of c++17.  I am increasingly believing that this scheme of
trying to avoid a capable compiler on some systems isn't a good tradeoff
overall, and that systems with a compiler that's at all oldish are going
to need to build one that can compile 95% of what's out there anyway.
But that's orthogonal.