automake
[Top][All Lists]
Advanced

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

Re: [PATCH] build: use automake's --silent-rules option when possible


From: Jim Meyering
Subject: Re: [PATCH] build: use automake's --silent-rules option when possible
Date: Sun, 29 Mar 2009 16:00:12 +0200

Thomas Dickey wrote:
> On Sun, 29 Mar 2009, Jim Meyering wrote:
>> Ralf Corsepius wrote:
>>> Jim Meyering wrote:
>>>> I like automake's upcoming --silent-rules option enough
>>>> that I'm making it the default (when possible) for coreutils.
>>> Well, if you think such a step to be helpful, I disagree.
>>
>> Then you can build with "make V=1".
>>
>>>> Since I bootstrap using automake from its "next" branch, it's
>>>> enabled for me.  And that translates to enhanced Makefile.in
>>>> files in the tarballs I generate.  The net result is that when
>>>> you run "make" (using distributed Makefile.in files), you'll
>>>> see something like this:
>>>>
>>>>  ...
>>>>  CC  id.o
>>> Now your users won't see the "silent bugs" your package comes with.
>>>
>>> I am seriously asking: Why are you doing this?
>>
>> I find it far easier to spot compiler warnings this way.
>> That's essential, when not using -Werror.
>
> well (recalling previous discussion), the reason that Ralf's complaining
> is that while it makes working on your program simpler it makes
> finding bugs in _automake_ harder.

If you think seeing those long gcc command lines in a *coreutils* build
will help you track down bugs in automake, you're welcome to use "make V=1".
It's just no longer the default.

Besides, considering that automake is so robust and stable these days,
why should I sacrifice coreutils development efficiency for the
dubious promise of increased ease of spotting automake bugs?
Even if by "bugs in automake", you mean "bugs in coreutils' Makefile.am
files", it's not a worthwhile trade-off.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]