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.