On 09/19/2012 03:14 PM, Jeffrey Walton wrote: > On Wed, Sep 19, 2012 at 5:01 PM, Eric Blake <eblake@xxxxxxxxxx> 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 eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
