Re: A better method to require compiler features

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

nia <nia%NetBSD.org@localhost> writes:

> On Thu, Jul 13, 2023 at 10:12:49AM -0400, Greg Troxel wrote:
>> You didn't address c99 and other things that might be in the same class,
>> but it seems that the USE_CXX_FEATURES should have a USE_C_FEATURES
>> analog, with c99, c10(?) and whatever else has or will come along.  I
>> see that as both a good thing to do and necessary to adopt "don't put
>> c99 in USE_LANGUAGES".  I'm guessing you agree but the discussion has
>> just been about the harder case of C++?
>
> I've thought about this, c11 is actually where it matters most
> currently. And has_include. Maybe USE_CXX_FEATURES could be used
> for both, there is certainly some overlap when it comes to things
> like compiler builtins and the desire to use e.g. AVX intrinsics.

We have to accomodate c(89) vs c99 vs c11 somehow.  I think it has to be
declarative, so we end up with no "GCC_REQD" for things that can be
described as language version/feature.  The details I am unclear on.  (I
don't care if we stick c99 and c++11 in the same feature variable.)

I am guessing you will prepare a patch for review and people can think
about something actual; it seems like abstract discussion has been about
as useful as it can be.

Others haven't spoken up much; I think where we are satisfies most
concerns raised earlier, but @all please speak up if not.

> The problem is that the most reasonable shortening of "C language
> families" is already taken by a compiler based on LLVM.

If you are referring to language/flavor vs family/language, then I don't
think that matters much, as long as the semantics are clear.

>> Perhaps FAIL_UNMET_COMPILER_REQUIREMENTS?
>
> I think I have decided on "ALLOW_NEWER_COMPILER" (default yes).

That sort of implies that if one has bootstrapped with a newer one it
won't work, but as long as its documented to break in the cases we are
talking about that seems ok.