Re: How to get autoconf to respect CC="gcc -std=c89"?

Niels Möller wrote:
> [...]
> Jacob Bachmeyer <[email protected]> writes:
>
>   
>> Niels Möller wrote:
>>     
>>>   AC_C_STANDARD_VERSION([c89 c99])
>>>
>>> is a bit meaningless; if compiler has c89, that's what will be used, and
>>> if it doesn't have c89, it won't have c99 either. 
>>>       
>> Free compilers may behave that way, however I have vague memories of a
>> compiler that dropped support for K&R function definitions many years
>> ago, long before GCC did.  Since Autoconf seeks portability, including
>> to non-free systems, preferring C89 but accepting C99 is reasonable to
>> express.  There may be non-free compilers out there that do not accept
>> C89 but do accept C99.
>>     
>
> I would have expected that every input that is valid c89 also is valid
> c99, so that support for c99 strictly implies support for c89. But there
> may be some corner case I'm not aware of.
>   

I believe that Autoconf effectively tests for declared support, so a 
compiler lacking a C89 mode will appear to not support C89, even if C99 
is a strict superset of C89 and the compiler /does/ support C99.

>> Some quick tests here suggest that "patsubst(patsubst([c99 c89], [c]),
>> [ ], [, ])" should do that trick.
>>     
>
> I'm trying for something a bit more complicated, which allows additional
> white space as well as capital C89, but still rejects unknown versions.
>   

8<------ [test.m4]
changequote([,])dnl
define([convert_list], [patsubst(patsubst($1, [[Cc]]), [ +], [, ])])dnl
define([test], ["$1" -> "convert_list($1)"])dnl
test([c89 c99])
test([C99 c89])
test([C11   c89 c99])
8<------

I believe the "convert_list" macro in the above test file fulfills the 
translation requirements, but validation is a separate matter.  
Validating the result should be easier after it has been normalized to a 
comma-delimited list of numbers.  Since I believe the proper name of the 
language is "C" (uppercase), normalizing case in an "unknown C language 
edition" error should be fine.

>> How about "error:  AC_PROG_CC_STANDARD_EDITION used after AC_PROG_CC
>> invoked"?
>>     
>
> I agree that's better. (It will still trigger also on repeated
> AC_PROG_CC_STANDARD_EDITION, but maybe error message is good enough
> despite that?)
>   

Simple solution:  "error: AC_PROG_CC_STANDARD_EDITON used twice or after 
AC_PROG_CC invoked"  :-)


-- Jacob