Re: howto restrict Warnings to non-system files?

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

Ingo Krabbe wrote:

> [...]
>
> Your option may be usefull for some people, while some others won't like
> it at all.

Yes. every user should have the possibility to decide on her own.
The default is and should be to complain about all headers.

> I think it is part of an IDE or of yourself to filter the
> warning messages which you get.

Some packages would be more successful if they stopped
relying on 20 others. Not every gcc-user is a unix guru.

The avalanche of package download and install on non-linux systems
until gcc bootstraps is a real hindering wall for new gcc users.

They give up after the system-flex comes instead of gnu-flex or
autoconf missing or gmake or grep or if sed is not patched correctly and
other things that brought tears to my eyes. I bootstrapped gcc several 100
times
on hpux and I hate it by now

Of course You are right:  I can do it on my own.
But it still is nicer to have it built in.

> From my point of view a Compiler has not
> to satisfy free software critisizers but developers.

What if the developers are free software critisizers or vice versa?

A compiler has to satisfy its users, e.g. my colleague ,
a C++ beginner, looking at the 80-line error message caused
by simply wrong usage of std::string migrating to a non-standard
C++ compiler who has quite clear error messages. What a pity.
[Yes, I know this kind of error is hard to catch in a fine way]

> From that point of
> view GCC is a state of the art product which one can rely on.

IMHO it is far away from being state of the art, because
its user-interface is not transparent, is not WIWIWYG,
has no nice or readable output and needs post-processing.
Even option --help output is wrong (see other posts)

Yes! It is state of the art. Of course. maximum ANSI compliance.
I like it. I use it. GCC forever.

> I'm
> sometimes worked with other Compilers like VisualC++ or Solaris SC5.0
> which are nice products too, shipped with thousands of pages of
> documentation and for thousands of dollars. I haven't seen any tool which
> you can rely on more than on GNU CC and thats what a compiler really
> needs.

I never felt like I could trust the binaries produced by gcc.
Well, to be honest, this is true for any compiler ...


> Of course some options are nice, but the compiler has enough options yet.

One little option  (-Wnocomplain-on-own-headers) is missing ;-)

> Just postprocess the output and you are happy. Don't always rely on others
> when you have to do your job.

I should not have said it is a request for a feature. I should have said:
It is a proposal for improvement. Treat it as such a thing.

> And autoconf and such tools are the only way
> to keep your sourcetree clean, if the job you have to do is big enough.
> Write a Makerule on your own which filters the output of the compiler, or
> do you call the compiler yourself on the commandline ?

nope. 4 Makefiles with 900 lines do the job
(adding one more line today)

> Last but not least, have you ever read a compiler critic ? One of the most
> important part is reliability, the next one is speed and finally code
> size. Reliability is hard to measure, but I have never read that gnu cc is
> shit.

Gcc is no shit. It only has a big potential in user interface improvements.
Good interfaces are the key to success of software.

> The compiler developing people are busy enough optimizing the code
> of GNU CC against speed and code size, which is some times more important
> than introducing some nice to use options. It may be that next christmas,
> such an option will appear.

I do not mind if this feature comes in 2013.
I do mind if people say it is not useful to have it.

I once heard about a  $20 Million-CAD/CAE-project
which had a really cool internal engine with every feature
one can think of (e.g. distributed concurrent development,
automatic generation of piece assembling docs etc.).
Nevertheless the project had little success, because the
user interface was hard to learn and not easy to handle.

I do not want gcc to follow that path. But I think this may happen.
This is why I do not stop posting improvement suggestions
and user's experiences to gcc-MLs

I forgot: Any developer out there who can tell me
which files are the ones with the error messages?


Markus