[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] Extend AC_PROG_CXX to check for standards conformance

From: Paul Eggert
Subject: Re: [patch] Extend AC_PROG_CXX to check for standards conformance
Date: Mon, 21 Jan 2013 10:02:01 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]