GNU bug report logs -
#12501
Automake generated makefiles can be less verbose when building with silent rules
Previous Next
To reply to this bug, email your comments to 12501 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#12501
; Package
automake
.
(Mon, 24 Sep 2012 07:38:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Hib Eris <hib <at> hiberis.nl>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Mon, 24 Sep 2012 07:38:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi all,
I think Automake generated makefiles can be a little less verbose when
building with silent rules.
Please consider attached patch.
Thanks,
Hib Eris
[0001-Do-not-echo-targets-when-building-with-silent-rules.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-automake <at> gnu.org
:
bug#12501
; Package
automake
.
(Tue, 02 Oct 2012 15:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 12501 <at> debbugs.gnu.org (full text, mbox):
tags 12501 + moreinfo
severity 12501 wishlist
thanks
On 09/24/2012 09:35 AM, Hib Eris wrote:
> Hi all,
>
> I think Automake generated makefiles can be a little less verbose when
> building with silent rules.
> Please consider attached patch.
>
> Thanks,
>
> Hib Eris
>
> From b1ab343e3e5c83e3da99a34924acf9c68bd4ee72 Mon Sep 17 00:00:00 2001
> From: Hib Eris <hib <at> hiberis.nl>
> Date: Mon, 24 Sep 2012 09:29:56 +0200
> Subject: [PATCH] Do not echo targets when building with silent rules
>
> ---
> automake.in | 2 +-
> lib/am/subdirs.am | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/automake.in b/automake.in
> index b165855..5b383a0 100644
> --- a/automake.in
> +++ b/automake.in
> @@ -4476,7 +4476,7 @@ sub handle_all ($)
> # things explicitly.
> $output_all .= ("all: @local_headers"
> . "\n\t"
> - . '$(MAKE) $(AM_MAKEFLAGS) '
> + . '$(AM_V_at)$(MAKE) $(AM_MAKEFLAGS) '
> . (var ('SUBDIRS') ? 'all-recursive' : 'all-am')
> . "\n\n");
> depend ('.MAKE', 'all');
> diff --git a/lib/am/subdirs.am b/lib/am/subdirs.am
> index 005483a..b430d21 100644
> --- a/lib/am/subdirs.am
> +++ b/lib/am/subdirs.am
> @@ -56,7 +56,7 @@ $(am__recursive_targets):
> *) list='$(SUBDIRS)' ;; \
> esac; \
> for subdir in $$list; do \
> - echo "Making $$target in $$subdir"; \
> + $(AM_V_P) && echo "Making $$target in $$subdir"; \
> if test "$$subdir" = "."; then \
> dot_seen=yes; \
> local_target="$$target-am"; \
> -- 1.7.5.4
>
Hmm... I fear that this change would actually make the makefile
output *too* silent, possibly impeding debugging or problem diagnosis
in a serious way. But I'm not sure if this is actually the case,
or if I'm just being overly wary. Would any other automaker like
to chime in with his opinion?
Anyway, the best way to make an "informed decision" would be to try
out Automake, patched with this diff, on few real-world package (GNU
coreutils and GNU autoconf comes to mind), with GNU and non-GNU make
implementations alike, and seeing how the make output looks when
everything goes smoothly, and then how it looks when there are errors
(e.g., errors compiling a file, permission errors modifying or
creating a file, and even syntax errors in a subdir Makefile). Would
you be willing to give this experiment a try, later posting here the
output and impressions you get? This might be overkill for such a
minor change however ...
Waiting for feedback,
Stefano
Added tag(s) moreinfo.
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 02 Oct 2012 15:11:02 GMT)
Full text and
rfc822 format available.
Severity set to 'wishlist' from 'normal'
Request was from
Stefano Lattarini <stefano.lattarini <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 02 Oct 2012 15:11:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 257 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.