From: Eli Zaretskii <eliz@gnu.org>
To: Andrew Burgess <aburgess@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb/doc: use silent-rules.mk in the Makefile
Date: Sat, 13 Apr 2024 10:02:24 +0300 [thread overview]
Message-ID: <86wmp1rbi7.fsf@gnu.org> (raw)
In-Reply-To: <87frvq43gj.fsf@redhat.com> (message from Andrew Burgess on Fri, 12 Apr 2024 23:32:28 +0100)
> From: Andrew Burgess <aburgess@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Fri, 12 Apr 2024 23:32:28 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> gdb/doc/Makefile.in | 158 ++++++++++++++++++++++++--------------------
> >> gdb/silent-rules.mk | 1 +
> >> 2 files changed, 86 insertions(+), 73 deletions(-)
> >
> > Doesn't this silence too much? Can you should the output of each rule
> > after the changes?
>
> Yes you can. As with the rest of GDB, if you do:
>
> make all-gdb V=1
Yes, I know. But that's not what I meant, sorry for being unclear. I
meant to ask _you_ to show the output of each rule that you change to
be silent, so that I could compare that with what it outputs
un-silenced, and decide whether we remove too much from the output.
I've now tried to figure that out by reading the silent-rules.mk
macros, and I feel that, indeed, in some cases we silence too much,
without (IMO) a good reason. For example:
> gdb.1: $(GDB_DOC_FILES)
> - touch $@
> - -$(TEXI2POD) $(MANCONF) -Dgdb < $(srcdir)/gdb.texinfo > gdb.pod
> - -($(POD2MAN1) gdb.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \
> + $(ECHO_GEN) touch $@
> + $(SILENCE) -$(TEXI2POD) $(MANCONF) -Dgdb < $(srcdir)/gdb.texinfo > gdb.pod
> + $(SILENCE) -($(POD2MAN1) gdb.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \
> mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1)
> - rm -f gdb.pod
> + $(SILENCE) rm -f gdb.pod
This completely conceals the fact that we run texi2pod and pod2man,
ending with just a single vague
GEN gdb.1
I think significant commands should be shown to the user, for better
"situational awareness". The analogy with compilation and linking
here, if that's what served the model for these changes, is IMO
incomplete: when we compile or link, seeing just "CXX foo.o" or
"CXXLD gdb" is enough to tell us what happens, whereas with the
generic "GEN foo" we don't really know what happens at all.
So my preference would be for having the above emit something like the
below instead
TEXI2POD gdb.pod
POD2MAN1 gdb.1
And similarly with the likes of
> annotate.pdf: $(ANNOTATE_DOC_FILES)
> - rm -f $(ANNOTATE_TEX_TMPS)
> - $(TEXI2DVI) --pdf -I $(srcdir) $(srcdir)/annotate.texinfo
> + $(SILENCE) rm -f $(ANNOTATE_TEX_TMPS)
> + $(ECHO_GEN) $(TEXI2DVI) $(SILENT_QUIET_FLAG) --pdf -I $(srcdir) \
> + $(srcdir)/annotate.texinfo
Why emit just
GEN annotate.pdf
? I'd prefer something like
TEXI2DVI annotate.pdf
instead.
Does this make sense?
next prev parent reply other threads:[~2024-04-13 7:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 17:00 Andrew Burgess
2024-04-12 18:31 ` Eli Zaretskii
2024-04-12 22:32 ` Andrew Burgess
2024-04-13 7:02 ` Eli Zaretskii [this message]
2024-04-15 13:55 ` Andrew Burgess
2024-04-15 14:18 ` Simon Marchi
2024-04-16 7:48 ` Andrew Burgess
2024-04-16 8:47 ` Andrew Burgess
2024-04-16 15:01 ` Simon Marchi
2024-04-17 21:00 ` Andrew Burgess
2024-05-08 17:46 ` Andrew Burgess
2024-05-26 18:20 ` Joel Brobecker
2024-05-26 22:02 ` Andrew Burgess
2024-05-26 22:58 ` Andrew Burgess
2024-05-28 15:25 ` Tom Tromey
2024-04-15 14:37 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86wmp1rbi7.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).