On 01/21/2013 05:46 AM, Roger Leigh wrote: > For both C and C++, I think there are some considerations > here where it does make sense: > > - If my project supports language standard n, enabling > standard n+1 or n+2 enables language features which are > actively harmful to use, since unintentional introduction > of later language features will break building on systems > which don't support it. Yes, if this were a real problem, we'd have to do something about it. But for C, it's not, and it hasn't been a problem ever since Autoconf was introduced. Historically, the biggest problem in this area was when C89 supplanted K&R C; and even back then, Autoconf was firmly in the "let's default to the latest version". This approach worked fine then and works even better now. > - If my project supports language standard n, and autoconf > autodetects n-1, configure will succeed unless I do > additional feature tests. It will of course fail at > compile time, but the fallbacks are essentially useless to > me. They may not help, but in practice they don't hurt. Right now, for example, one would be crazy to insist on C11, as that would prevent too many people from using one's package. By the time it's safe to insist on C11, almost everyone will have it, and the few people who don't have it will all know what to do when the fallback kicks in. I'm not saying that we shouldn't do anything in this area, but I am leery about adding a half-dozen published macros and the resultant complexity in documentation for a feature that hardly any developer will actually need, a feature that (unless carefully documented) is likely to confuse developers into thinking that they need it. I think the main issue here is philosophical. Autoconf is designed to tailor the program to whatever the host provides. The C and C++ standards follow a different tradition: they specify what the host must provide. Both approaches work, indeed the Autoconf way depends on a minimal standard substrate, but once you're in the Autoconf world it's better to do things the Autoconf way. This is why, for example, there's no Autoconf macro for specifying which POSIX version the package wants, or which version of the GNU C library the package wants. There's just AC_USE_SYSTEM_EXTENSIONS, which gives you everything, and that's good enough. The sort of standards-lawyering that requires the use of macros like _POSIX_SOURCE is exactly the sort of thing that Autoconf is supposed to liberate developers from. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
