[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]


On 11/05/2009 05:27 PM, Bastien Nocera wrote:
On Thu, 2009-11-05 at 16:17 +0100, Ralf Corsepius wrote:
On 11/05/2009 04:04 PM, Bastien Nocera wrote:
On Thu, 2009-11-05 at 09:43 -0500, Steve Grubb wrote:

I was looking at a package's build logs to see what kinds of problems gcc is
reporting for the code and found a lot of lines with "CC  object_name" and
nothing else. This is really not helpful when you scan koji build logs or look
for problems. Should we have a policy of requiring "--silent=no" configure
option for packages that are hiding gcc warnings?
Yes, definitely.

GCC warnings will still show up, otherwise it means you don't have a
high enough level of warnings in the package.

V=1 passed to make is enough to show the full command-lines.
Unless a package already uses "V" otherwise.

I don't think that disabling silent would help one bit if you're just
looking for warnings, because it would show them anyway.
Wrong, Broken CPPFLAGS and CFLAGS don't show up as warning even when
they kill a build.

Those weren't warnings in the first place,and certainly not gcc
> warnings,

Not quite.

Whether gcc issues warnings/errors depends upon CFLAGS/CPPFLAGS (e.g. optimization levels) and other factors (e.g. architectures, GCC version/patches, tools being used underneath).

On a wider scope, in general, CPPFLAGS/CFLAGS can cause non-FPC compliant binaries (eg. using -O3, -m<obsure option>), deeply hidden compilation issues (-I/usr/include) or non-functional binaries (-DSYSCONFDIR="/home/nocera/").

Suche kind of issues are hidden when using AM_SILENT_RULES, though they often are the cause for deeply hidden and hard to trace down issues.

Finally, IMNSHO, AM_SILENT_RULES is "greasy kid's stuff". People who are using and/or endoring them have no clue about what they are doing.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]