AM_SILENT_RULES

[Ralf Corsepius]

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