Re: RFE: macro for warning at configure-time if CFLAGS includes -Werror

[Eric Blake]

On 09/19/2012 03:14 PM, Jeffrey Walton wrote:
> On Wed, Sep 19, 2012 at 5:01 PM, Eric Blake <address@hidden> wrote:
>> I just helped someone debug an issue today where their configure run was
>> getting weird results, because they had called './configure
>> CFLAGS="-Wall -Werror -O0 -g"', and the -Werror was causing several
>> tests to guess wrong.
>>

> The best solution for users is likely to be similar to "do the sane
> thing so things work." If that means hding -Werror so things work as
> intended, that that is probably one of the better paths to take.

That would be more invasive; I really don't want to change AC_PROG_CC
itself for fear of breaking backwards compatibility for users unprepared
for configure to hide -Werror from the rest of make.  Blindly ignoring
-Werror might trigger its own problems (I know of at least one situation
where the configure.ac writer intentionally wanted to test whether a
particular library header triggered warnings, to know whether it was
safe to use -Werror elsewhere in the project; silently stripping -Werror
from CFLAGS for the duration of configure would make this situation
harder to probe for).  In other words, you generally want to configure
for the exact environment that make will also be using, and hiding
-Werror means you have two different environments.  On the other hand,
the rest of your project is generally written in decent coding style,
while configure tests tend to be bare bones abuse to intentionally probe
what features are available, and therefore more likely to trigger warnings.

So maybe your idea has merit, and in fact, I think the two ideas are
orthogonal and could both be implemented (although configure.ac writers
would only ever need to use one of the two versions).

> 
> As a dumb user, I want to use a cookbook. That means I want to do a:
> 
>    ./configure CFLAGS="-Wall -Wextra ...."
> 
> I don't want to have to learn how to use autoconf, automake, and make.
> I don't want to subscribe to mailing list to make things work. I just
> want it to work as expected.

For this to work, we'd need a way for the configure.ac author to state
that temporary -Werror scrubbing during configure is okay, by invoking a
macro _prior_ to AC_PROG_CC.  If that macro has been used, then
AC_PROG_CC would record whether -Werror is present, strip it from CFLAGS
(or better, morph it to -Wno-error, so that the edit can be undone later
even if CFLAGS has been appended to by the rest of configure), run the
rest of configure without error checking, and then at the end,
re-instate CFLAGS back to the user's request.

> 
> The dumb user (me) is likely not the same person who decided to use
> the tool chain (the maintainers). Maintainers are probably much more
> savvy users.
> 
> No disrespect intended.

None taken.  However, I still think that this is enough of a change in
default behavior that it has to be something that configure.ac authors
have to request, rather than something forced on them by default, since
not all packages behave equally in the presence or absence of -Werror.
And again, my original proposal, when given your use case as a user,
would result in something like:

$ ./configure CFLAGS="-Wall -Werror"
warning: -Werror detected in configure-time CFLAGS; if this does not
  work the way you expected, then configure without CFLAGS and later
  run 'make CFLAGS=-Werror'

That does not mean that the end user has to know anything about touching
configure.ac or rerunning autoconf.  Of course, I'm arguing that
_someone_ has to originally touch configure.ac before either my proposed
warning or your proposed -Werror sanitizing can take place at configure
time, but that one-time edit really is a maintainer's role.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature