"Zack Weinberg" <zack@xxxxxxxxxxxx> writes:
> Do we want "in order of preference" or do we want "of all the entries
> in the list, pick the most recent edition that the compiler supports"?
> I can see arguments either way. Bob, do you have an opinion?
Depends a bit on what we want the macro to do, more on that further
below.
> I think the macro should accept four-digit years (c1989, c1999, c2011)
> as well as two-digit years, and I think "c90" (and "c1990") should be
> recognized as a synonym for "c89".
Makes sense to me.
> Maybe it should also accept bare numbers?
My preference would be to not do that (or, alternatively, have 4-digit
years as the *only* format).
> Because Autoconf *used* to support this many years ago, if someone
> puts the word "traditional" in the list,
Not sure it's worth a specific error message for this case, if it's an
argument to a macro that didn't exist in older autoconf versions.
>> * Error if used after AC_PROG_CC, or used multiple times.
>
> I'm not sure if it should *error*. We have AC_BEFORE, which is
> documented as being for this kind of thing, and it just warns.
I don't have a strong opinion if it should be a warning or error. Not
familiar with AC_BEFORE, will have to look that up.
>>(and if that's a good name).
>
> Internally, the terminology is "STDC_EDITION", and I like "edition"
> because it emphasizes that it's not the *compiler's* version number
> we're talking about. Since the macro takes a list, it might make
> more sense to have the name be in the plural: AC_something_EDITIONS.
I don't have a strong opinion. To me, it's reasonable to talk about a
"version" of the language specification, independent of the software
version of available compilers.
> Historically, we had AC_PROG_CC_{C89,C99,STDC,TRADITIONAL} that
> treated "select this standard edition" as a property of the compiler,
> but those are all obsolete and more recently we have been naming "find
> out if the compiler supports this feature of C" macros in the AC_C_
> namespace instead.
To me, those macros sounds rather useful, if AC_PROG_CC_C99 meant
roughly "this project wants a compiler that supports C99", and which
fails if C99 mode is missing and can't be enabled.
To me, the advantage of the AC_PROG_CC behavior (and variants enabled by
my patch) over AC_PROG_CC_C99 is that it makes autoconf probe for
multiple versions, and one can then check ac_cv_prog_stdc for what was
available.
> * If configure.ac has AC_C_STANDARD_VERSION([c99]) and the compiler
> only supports C89, ./configure should error out (use AC_MSG_ERROR).
> Analogously for any other "compiler is too old for this" situation.
That's in one way reasonable, but to me, it also seems a bit
inconsistent with the default behavior. My understanding is that
AC_PROG_CC doesn't error, it just sets ac_prog_cc_stdc=no, if a C
compiler is available but not supporting c89.
> * If the compiler only supports *newer* editions than the newest one
> in the list, on the other hand, I think ./configure should issue a
> warning (AC_MSG_WARN), select the closest edition possible, and
> proceed. Does anyone disagree with that? Bob?
Hmm, sounds like you envision AC_C_STANDARD_VERSION([c99]) doing a bit
more than I ask for. To me, it means that I prefer (or maybe, require)
at least c99, but I don't care if compiler happens to accept later
language features as well.
I feel rather strongly that autoconf shouldn't automatically disable
compiler features for me. I just want it to stay out of the way when *I*
explicitly enable or disable compiler features, like with CC='gcc
-std=c99' or CC='gcc -std=c11'. (It's ok if autoconf interferes when my
configuration conflicts with the package's oldest supported language
version; my interest is in being able to test with various
non-conflicting compiler settings).
To me, desired action on autoconf's part is to probe for c99 support,
and attempt to enable if it is not on by default. But not care to probe
for, enable, *or* disable, support for later versions.
> * Tests -- most importantly, a test that, if you say
> AC_C_STDC_EDITIONS([c89]) or AC_C_STDC_EDITIONS([c99]),
> the compiler is put into the mode you asked for, even if
> it supports newer editions, since that's the whole point
> of the feature.
By above, I disagree slightly about the point of the feature. But I
agree that tests are needed. Is it ok to assume that gcc is available
for tests to use, or would I need some completely mock compiler, like an
extended ./mycc? I've had a quick look at tests/c.at, but I'm not at all
familiar with this framework, so it will be a bit of cargo cult
programming.
>> I'd be happy to sign FSF copyright assignment forms, if required.
>
> I think this is big enough, or will be, that we do need that, yes.
Ok, I'll try to get that going then.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
