Re: howto restrict Warnings to non-system files?

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

Ingo Krabbe wrote:

> On Thu, 28 Jun 2001, Markus Werle wrote:
> >
> > One little option  (-Wnocomplain-on-own-headers) is missing ;-)
> >
>
>         And thats the problem exactly. Whats about changing from one
> stdc++ library or stl library to another. Ok thats not usefull anymore
> since the libstdc++ works in our days. Nevertheless it doesn't really
> belongs into the gcc tree. It is a subtree.

The manifold of possible options can reflect our distinguished
view on gcc:

-Wno-warn-on-all-own-headers
-Wno-warn-on-own c++-headers

At least Your flexible approach fits well here:
-Wno-warn-on="/opt/gcc-3.0"

> That option may come, but
> it will be as uneasy to use as a simple grep command. You don't need to be
> a unix-guru to know grep.

When the form of the warnings (layout, line breaking etc.) changes
I always will have to adopt the Makefile's grep portion again.
It was just comfort I asked for.

Who guarantees grep on all systems equal?
If I was using only linux systems I would have no problems here.
But now the Makefile has another
if-on-that-system-use-this-grep and on the other
use another, maybe hp's /bin/grep, but the commandline options differ
so now I will check if on hpux, if I can find a gnu-grep or not
(the latter is true for some of ours) change the options to be hp-conforming
(lack of -3 option on that platform, so maybe the whole
grep command must be changed)

Thinking longer on the grep proposal leads to the conclusion:
again 15-30 more lines in my Makefile to run
a) on homelinux, b) on linuxatoffice c) hpuxatoffice
what if we buy an sgi or someone asks for a win95 version?

ifneq (,$(findstring hpux, $(OSTYPE)))
  CXX = /opt/FREE-SOFTWARE/gcc-3.0/bin/g++

  ifneq (/bin/grep, $(findstring$(shell which grep))
      GREP_COMMAND=...
  else
    ...
[snipped a lot of ifs and endifs]

Who really wants to write Makefiles by hand anyway?
I have to write them just because I did not have the time to look at
autoconf or Cygnus configure and m4 and perl.
Got the point?

A few lines written in C can free me from this burden.

I once tried to find out how much time it will take to set up
a gcc developer's environment on win98. cygnus tree was out-of-date
somehow (I think I read it is no longer maintained for the public)
so I tried to find out what packages I _really_ need.

Then I decided that it is easier to install a linux distribution on
that machine. This was not possible for some other reasons, so
this machine is lost as a test-platform for gcc.

Gcc claims to be platform independent but depends on too many other
UNIX packages, which to port is a little nightmare for normal users
who _just_ wanted to _use_ gcc/g++ and nothing else.
Some of the dependencies are OK, but if the number can be reduced
we should take the chance.

> If a begginner starts he should work with a IDE
> first. Not even the IDE's know such filtering of error messages.

>         By the way it may be more usefull to really catch and drop out
> when the programmer does common errors, like your c++-beginnig colleague
> does them on using std::string.

Yes, this was just another example to stretch out that the
interface has potential for improvements.

> Your option you describe would only be
> okay if the compiler user can define which headers should be viewed as
> "OWN".

Agreed.


Markus