Re: AC_*/AM_* macros for options

[David A. Wheeler]

Russ Allbery <address@hidden>:
> The last time I turned [-Wconversion] on for a project, the only warnings it 
> produced
> were either complaints about code that was provably fine without changes
> or bogus warnings about ntohs.  I fixed the ones that were fine anyway,
> just because I'm anal like that, and then turned it off because I always
> use -Werror when doing development builds and am not willing to turn on
> warnings I can't suppress in every circumstance...
>... But I agree
> with Paul's point in general: it's a warning that doesn't work well with
> code that's dealing with corner cases, like types that could be signed on
> some hosts and unsigned on others.

Clearly some flags shouldn't be turned on by default, and if some are
turned on by default, there needs to be clear and simple ways to control them.
Completely agree.

> I'm currently only using warning flags for developer builds.  I'm still
> making up my mind on whether enabling them for production builds would
> find more problems than it would cause.

If warning flags are turned on by default by autoconf, then any developer who 
uses
it will automatically learn about some problems that they currently don't know 
about.
Typically it's more painful to turn on warning flags later instead of the 
beginning.

I think it's helpful for production builds, too.
Production builds are often created by people who aren't the original 
developers.
If there are a lot of warnings, that's a hint to the production builder that he 
might
want to check further.  Maybe they're all legit... or maybe the original 
developer keeps
making bone-headed mistakes.  Warnings tell people that something
might not be okay, and where to look to find out more.

--- David A. Wheeler