Bob Friesenhahn <bfriesen@xxxxxxxxxxxxxxxxxxx> stated: > I don't think that it is a particularly good idea to enable any > warning options by default in a package unless the warnings are likely > to indicate that the code the developer should have already perfected > is somehow faulty (e.g. unexpected interface definition or missing > prototype) on the system it is being built on. > > Usually only the developers of a package are interested in seeing and > fixing warnings. Warnings are only a cause for concern (usually undue > concern) for others. I strongly disagree. I think many *end-users* want to know about warnings too. By end-users, I mean people who are NOT developers but are compiling the code, including distro packagers. If I compile software and I can see that it triggers LOTS of compile-time warnings, that’s a big hint on how much care the developers are taking in the quality of their software. It’s not a perfect correlation; good software can sometimes trigger many errors, and bad software can be warning-free. Still, when you’re looking at new-to-you software, these warnings are a data point worth knowing. This isn't just speculation. I just recently downloaded a new-to-me program (in this case, Metamath), and to roughly measure its quality, I simply turned on gcc warning flags (in my case "-Wall -Wextra") to see how clean it was when I compiled it. It turned out there were *NO* warnings. Sure, that doesn’t mean the software is perfect, but that *did* suggest to me a quality of care. I think *many* people agree that warnings can be useful. E.G., Keith Packard recently worked to eliminate the warnings from X windows (http://keithp.com/blogs/xserver-warnings/). He said, “One of the developers was looking over my shoulder while the X server was building and casually commented on the number of warnings generated by the compiler…. I felt like I had invited someone into my house without cleaning for months — embarrassed and ashamed that we’d let the code devolve into this state.” But how can we make sure that developers are more likely to see or heed these warnings? Well, if they're on by default, developers are more likely to see them of course. But it's important that *users* also see them, if for no other reason than that developers will know that *users* who compile the program will see the same errors (and thus have an incentive to fix them). And Dale Visser is also working on a way to portably *control* these flags for cases where a particular flag isn't appropriate (or should be added), so there's no problem if the default is not so great for your specific program. I think it is NOT a good idea for a developer to see warning messages in his builds, but then suppress them for end-user builds. Better to suppress them with good reason for all builds, if they are not relevant! Or if not, at least document why certain warnings are not being "fixed"... and they're way more likely to be fixed or documented if the users can easily see them. --- David A. Wheeler _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
