public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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?

  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).