Re: [warnings] tagging warnings about options themselves

[DJ Delorie <dj at redhat dot com>]

> You mean, an option to control whether the compiler warns about
> options?

Sadly, yes.

> Personally I think this is going a bit overboard.  I can see the
> advantage to being able to control every warning which can be
> produced by source code.  But these are bring produced based solely
> on the command line and, I suppose, the specs file.  I don't think
> we need an option to control warnings about what options you use.
> But maybe I'm missing something.

Well, two things:

1. If we can get to the point where every warning() call has an OPT_*,
   then we can change warning() to *require* an OPT_* and then we've
   locked in the new system - nobody could then add new warnings
   without being able to control them.  I was pondering a catch-all
   option to avoid an explosion of options, messy but effective.

2. We had a customer complain about it just today, which is why I
   looked into it.  Their policy is to use -Werror (I've seen that a
   lot) which means that *every* uncontrollable warning is going to
   stop their build cold.  Yes, they could (and did) change their
   build to avoid the warnings, but if we're going to (1) provide
   -Werror and also (2) add new warnings all over the place, we should
   take into account the problems that's going to cause.

The cases I see most often are when people upgrade the compiler, and
suddenly they can't build anything because of all the new warnings.
When it's something *they* add, yeah, they can just not add that.

The three options I pointed out, for example, might be unavoidable if
you're managing a range of builds from a common build system, and not
all compilers support exactly the same options.  During a migration,
you'd need to disable all the new warnings so that you can get product
out, while in the background you're working on avoiding the warnings.

But there are others, like target-specific warnings for -f options not
being supported.  If you're building for multiple targets, it's easier
to just ignore those warnings than to figure out how to customize each
build for each target.

On the other side of the project, there will eventually be an option
to selectively turn warnings into errors (like a selective -Werror).
You need to have all the controlled warnings tagged in order to use
that, and the more you tag the more strict your build policy can be.