"Kevin P. Fleming" <kpfleming@xxxxxxxxxxxxxxx> writes: > Hmm... I see your point, but wouldn't that then mean that the macro > would need to individually test for each C99 feature and store the > results into variables for the configure script to check? Yes, that's the basic idea. Though there would be lots of macros, not just one. One for each feature that your project needs. Many of these macros exist already, e.g., AC_C_INLINE. > Switching based on particular features they need sounds scary to me; What can I say? It's the Autoconf Way. It works better in practice than trying to switch on "C99" versus "C89", because real-world compilers are rarely that simple. > in a project where there are multiple developers who have been told > "our project demands C99 support from the build system", they will > feel free to use C99 features wherever they want. Sure. And such projects don't need to use AC_C_INLINE. That will simplify their Autoconfery and their codeing, at the expense of preventing them from porting to pre-C99 hosts. It's a tradeoff each project can make on its own. Personally, I don't advocate assuming C99 just yet -- only one C99 compiler exists right now, as far as I know, and it's not free -- but other people might reasonably disagree and Autoconf can cater to them too. Also, people can assume some C99 features, if they like. It's up to them. However, today I do advocate writing code that is portable to C99. That is why it's OK to change AC_PROG_CC_STDC to prefer C99 to C89, if both are available. People's code shouldn't assume the features of C89 that are incompatible with C99. > the project could suddenly stop building on systems it used to build on > because that compiler doesn't support all C99 features. That's fine, for projects that want to assume C99. Or perhaps I'm misunderstanding your scenario? _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
