Re: howto restrict Warnings to non-system files?

[Markus Werle <markus at lufmech dot rwth-aachen dot de>]

Martin Kalen wrote:

> It's not really that easy, is it?

implementation should be easy:
If gcc complains about a header it has processed this header
which means that it knows the full path to that file.
It cannot be too complicated to test this path against patterns and
silent down the messages for some of these.

> If gcc was to have special tables about it's "own" header files and
> start filtering out warnings and errors for them, then a warning
> and/or error option would not longer be 100% accurate as to what
> warnings and errors it would output. It would in a way be like
> "cheating" as compared to the standard.
>
> If you decide to use more aggressive warnings and the STL is written
> in a way that violates the rulesets in these warnings, then in my
> opinion it is most logical for gcc to output warnings and/or errors
> for it's own files.
>
> Clearly, you disagree

No I agree. I just thought it would be nice for the user to switch them
off,
if and only if STL header warnings (or others) are of no interest.
Of course the default behaviour should be to complain about everything
and every header.

> - but this is not just a simple "request for a
> new feature", I am sure you can see that the gcc developers must
> carefully think about this and that there are two distinctively
> different opinions to be held (and, of course, everything in between).

No, both options can live beside each other. It's an _additional_ feature

to invoke gcc with --supress-warnings-for-files-in=/opt/gcc-3.0
and --supress-warnings-on-own-headers

> Now, I am in no way whatsoever involved in the gcc development project
> but I just though I had to share my views with you and also advise you
> that I though the tone of your mail was very rude towards the
> developers of gcc. That might not have been your intention,

I am sorry for this. It was not my intention to insult someone or to be
rude.

> but my
> impression was that you are trying to "threaten" the developers to
> implementing a request for a new feature by scaring them with other
> projects that "might catch up".

No. I just wanted to hear:
"Yes, this is good as additional feature, and some volunteer yet to come
will
implement this in the next 20 years. Maybe it is you. The files you must
dig in are ..."
I understood earlier messages in the way that my proposal was absurd and
this is where I stood up to get this clear. I am a user who gets his
screen polluted
by warnings that do not help me any step further. This is what  I
consider as bug.
Yes, a true bug: the system does not do what I want.

To make it clear: I owe gcc-developers a lot. I owe free software a lot.
I am very interested in that this movement does not stop, but
I somehow feel that some projects are in danger to die a sudden death
if some things are going the way they do.

I am the one at our office who works hard to convince the fellows not
to rely on proprietary software but to join a great thing etc.
[ snip ... all arguments You can find news://*advocat*]

I am also the one who sees that user-developer-interaction for gcc
differs
from that of other projects in such a way that I sometimes get the
impression
that bug-reports or user-opinion are reacted on in a
let's-get-rid-of-this-manner. No one wants to know what

> Surely there must be more constructive
> ways of argumenting and trying to explain your opinion in the matter?

I will try to find a better way to express my opinion.


> And, lastly, you state that rejection of your request is a threat to
> the free software spirit - in the true spirit of free software, I
> would believe you are most welcome to implement anything you see fit
> for gcc yourself and submit a patch (that, of course, might be
> accepted or rejected by the maintainers).

If a feature request is made, and the feature is useful,
it is perfectly OK to reject it due to time lack or more important
things to do.

It is not OK to say the feature is useless. I disagree with people
who say this feature would not be an improvement.


Markus