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:
>>> Hello,
>>>
>>> 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.
<rant>
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.
</rant>
Ralf