shouldn't discard all output

[Marcus Brinkmann]

Hi,

I noticed that libtool discards output on second runs of gcc:

     burger$ libtool gcc -g -O -c foo.c
     gcc -g -O -c -fPIC -DPIC foo.c
     mv -f foo.o foo.lo
     gcc -g -O -c foo.c >/dev/null 2>&1
     burger$ libtool gcc -g -O -c hello.c
     gcc -g -O -c -fPIC -DPIC hello.c
     mv -f hello.o hello.lo
     gcc -g -O -c hello.c >/dev/null 2>&1
     burger$

   Notice that the second run of GCC has its output discarded.  This is
   done so that compiler warnings aren't annoyingly duplicated.

It is reasonable to assume that the second run should succeed if the first
did.  However, the point can be made that *if* it fails, the error might
indicate a serious problem (disk full, hardware problem, build chain
corruption), and that discarding this error is counter-productive.[1]

I think a reasonable compromise can be to discard the warnings, but leave
other (unexpected) failures intact.  So, instead redirecting the output, it
should specify -w (or the portable equivalent) to inhibit all warnings.  On
compilers without the possibility to inhibit warnings, it should probably
err on the safe side and do nothing.  This will lead to annoying duplicates,
but that's the price if you don't use gcc ;)

I don't know of other useful options that can be used in conjunction with -w
to achieve the goal of "as little bloat in the output as possible".  Maybe
there are.

Thanks,
Marcus

[1] It could be argued that in such a condition, the error value can't be
trusted anyway.  However, in real life, the error value often is a good
pointer to the problem.  Like sig 11 indicates a hardware problem, ENOSPACE
indicates not enough disk space etc.

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann              GNU    http://www.gnu.org    address@hidden
address@hidden
http://www.marcus-brinkmann.de