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

[Jim Meyering]

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.

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

[Russ Allbery]

Ralf Corsepius  writes:
> Jim Meyering wrote:

>> 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'm planning on doing the same thing with my packages because I think my
users will see the bugs *better*.  One of the problems with the default
Automake output is that it's very difficult, without redirecting output or
the assistance of a separate parsing program, to extract the warnings from
the long compiler strings.  This format makes the warnings *far* more
obvious, which is very useful.

The only thing that I'm worried about is not seeing the list of libraries
with which executables are linked.  That's the single piece of debugging
information about builds that I use the most often.

But the long, repetitive compiler lines, which are mechanically generated
and rarely contain useful information, get in the way of seeing bits of
output that are actually important.

-- 
Russ Allbery (r...@stanford.edu) 

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

[Ralf Corsepius]

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.


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? To me, such "silence" 
means cheating at one selves about the quality of a package and "playing 
down" the bugs a package is suffering from.


Sorry, if you find this rude, but think it needed to be said.

Ralf

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

[Alberto Luaces]

El Sábado 28 Marzo 2009ES 17:14:10 Jan Engelhardt escribió:
> On Saturday 2009-03-28 16:44, Ralf Wildenhues wrote:
> >Hi Bob, Jim,
> >
> >* Bob Friesenhahn wrote on Sat, Mar 28, 2009 at 04:40:16PM CET:
> >> On Sat, 28 Mar 2009, Jim Meyering wrote:
> >>> I like automake's upcoming --silent-rules option enough
> >>> that I'm making it the default (when possible) for coreutils.
> >
> >[...]
> >
> >>> CC  id.o
> >>
> >> What happens when things go wrong with the compilation command line? How
> >> will the user diagnose build problems in this Linux-kernel like mode?
> >
> >Use 'make V=1'.
>
> Which — I might add — is vastly better than cmake mentioned in
> previous discussions, which, as far as my knowledge goes, you have to
> rerun cmake and recreate Makefiles (gagh!).

No, cmake doesn't regenerate the Makefiles if you use make VERBOSE=1:

$ ls -l Makefile
-rw-r--r-- 1 alberto alberto 123740 mar 20 17:02 Makefile
$ make
[Compilation interrupted with CTRL-C]
$make VERBOSE=1
[Verbose ouput, compilation interrupted with CTRL-C]
$ ls -l Makefile
-rw-r--r-- 1 alberto alberto 123740 mar 20 17:02 Makefile

Re: Doesn't work: blah_PROGRAMS = $(EXTRA_PROGRAMS)

[Ralf Wildenhues]

* Daniel Richard G. wrote on Fri, Mar 27, 2009 at 08:54:10AM CET:
> >
> > Looks like automake is as confused as you are.  For now, here's a
> > simple workaround, using a helper variable that is not special to
> > automake:
> 
> Oh, a workaround's not a problem; the bug is very narrow. In my case, I just 
> assigned the same literal value to noinst_PROGRAMS, as only one or two 
> program 
> names were ever involved.

Sure, but if you had dozens there, then it would make a difference.
Others who encounter the same problem might have many.

> Just wanted to bring the bogus error message to your attention, not least 
> because it seems remarkable that this corner case has never been addressed 
> before!

Well, I haven't looked at this at all, but I bet it's another glitch in
the code that rewrite *_PROGRAMS variables to end in `$(EXEEXT)'.  This
rewriting is inherently error-prone, and turns up new bugs like this one
every now and then.  Which is why I tend to veto new features that add
more in-place variable rewriting.

Cheers,
Ralf

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

[Jan Engelhardt]

On Saturday 2009-03-28 16:44, Ralf Wildenhues wrote:
>Hi Bob, Jim,
>
>* Bob Friesenhahn wrote on Sat, Mar 28, 2009 at 04:40:16PM CET:
>> On Sat, 28 Mar 2009, Jim Meyering wrote:
>>
>>> I like automake's upcoming --silent-rules option enough
>>> that I'm making it the default (when possible) for coreutils.
>[...]
>>> CC  id.o
>>
>> What happens when things go wrong with the compilation command line? How 
>> will the user diagnose build problems in this Linux-kernel like mode?
>
>Use 'make V=1'.

Which — I might add — is vastly better than cmake mentioned in
previous discussions, which, as far as my knowledge goes, you have to
rerun cmake and recreate Makefiles (gagh!).

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

[Ralf Wildenhues]

Hi Bob, Jim,

* Bob Friesenhahn wrote on Sat, Mar 28, 2009 at 04:40:16PM CET:
> On Sat, 28 Mar 2009, Jim Meyering wrote:
>
>> I like automake's upcoming --silent-rules option enough
>> that I'm making it the default (when possible) for coreutils.
[...]
>> CC  id.o
>
> What happens when things go wrong with the compilation command line? How 
> will the user diagnose build problems in this Linux-kernel like mode?

Use 'make V=1'.

Cheers,
Ralf

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

[Bob Friesenhahn]

On Sat, 28 Mar 2009, Jim Meyering wrote:


I like automake's upcoming --silent-rules option enough
that I'm making it the default (when possible) for coreutils.
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


What happens when things go wrong with the compilation command line? 
How will the user diagnose build problems in this Linux-kernel like 
mode?


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

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

[Jim Meyering]

I like automake's upcoming --silent-rules option enough
that I'm making it the default (when possible) for coreutils.
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
 CC  kill.o
 CC  operand2sig.o
 CC  logname.o
 CC  pathchk.o
 CC  printenv.o
 CC  printf.o
 CC  pwd.o
 CC  runcon.o
 CC  seq.o
 CC  sleep.o
 CC  tee.o
 CC  test.o
 CC  timeout.o
 CC  true.o
 CC  truncate.o
 CC  tty.o
 CC  whoami.o
 CC  yes.o
 CC  base64.o
 CC  setuidgid.o
 CC  getlimits.o
 CC  su.o
 AR  libver.a
 CCLD  uname
 CCLD  chroot
 CCLD  hostid
 CCLD  nice
 CCLD  df
 CCLD  pinky
 CCLD  users
 CCLD  uptime
 CCLD  stty
 CCLD  [
 CCLD  chcon
 CCLD  who
 CCLD  chgrp
 CCLD  chown
 CCLD  chmod
 ...

rather than less-readable lines full of gcc command-line options.


>From 9f39fa8559a8f87e1199f11f6cee295ac8cf6781 Mon Sep 17 00:00:00 2001
From: Jim Meyering 
Date: Sat, 28 Mar 2009 12:48:24 +0100
Subject: [PATCH] build: use automake's --silent-rules option when possible

* bootstrap: Use automake's --silent-rules option.
---
 bootstrap |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/bootstrap b/bootstrap
index 27e4ec2..e834a2b 100755
--- a/bootstrap
+++ b/bootstrap
@@ -686,6 +686,12 @@ find "$m4_base" "$source_base" \
   -depth \( -name '*.m4' -o -name '*.[ch]' \) \
   -type l -xtype l -delete > /dev/null 2>&1

+# Use automake's --silent-rules option, if possible.
+automake="${AUTOMAKE-automake} --add-missing --copy --force-missing"
+(${AUTOMAKE-automake} --help) 2>&1 \
+| grep -e '^  *--silent-rules' > /dev/null \
+  && automake="$automake --silent-rules"
+
 # Reconfigure, getting other files.

 for command in \
@@ -693,7 +699,7 @@ for command in \
   "${ACLOCAL-aclocal} --force -I m4" \
   "${AUTOCONF-autoconf} --force" \
   "${AUTOHEADER-autoheader} --force" \
-  "${AUTOMAKE-automake} --add-missing --copy --force-missing"
+  "$automake"
 do
   if test "$command" = libtool; then
 use_libtool=0
--
1.6.2.rc1.285.gc5f54