From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 7EF263858D38 for ; Sat, 13 Apr 2024 07:02:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EF263858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7EF263858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712991748; cv=none; b=AE5Nq4tL+OY3zLhOSzavzfNTpTPttX7GJf5R5ByyyEKfOK8YPYLE8r8kSLAOUW+qjy9iASk/tKYs8G12Hs2xE6rWC2rKCFfNAFjJSwZAWUkFOnnENytrQ44w2Z7vNmuRBE+Gn6A5eVXBcJ/nxPTOCY+0NlQPgeS1beUj71szlLk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712991748; c=relaxed/simple; bh=mcXAh/3gHLRYleDfHNCuw/7Q7ljBIPAmQV/A/Tth3Ks=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=hzSx3xSQeiItO0YjnpOr0RmkgFbAS8tLc0Ubc8pOxB+b3G31JokwWQZirnXl84CuNdQGNoQPz3Xtb6m043YXTXBnp0Qu8xWv8G80HFKdEc+vQ7ERId6BJWBB1TlNcKYG3HXOcCvKguWShly0nB74LsM4UtZDwRv1R4jEpHw1iXk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rvXP8-000470-Be; Sat, 13 Apr 2024 03:02:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=a7KQXKQz4q9zqpwxzDeS5+Syytos7TUwo+IzKtFuejU=; b=CVCGdQOXeNP8 zd0flwxdRggicDjOM2xGigvlZk/yQBzJC/Wl2IP/R/8CGGc+CxQEvsAfAZ3bdJVRiUBBeoJXOul1y rhKtOs9aqYhkPWV1KEaLNfEQyMOL3P38TzikIGTdUXbKhLBqGvVT6VvwvUryDAFpbn+yt8EYxPD2l ZvTKy+Nhaess+NWYowUbnrnncXyI/1L0mHXuwEzHhYyEFziUHyhf88HcPyHggTNdqXDPTun+7yNJw upx4IEQUH5FQ2JRLK0jXkneyqzy0F2Zk97Kcq1fOxt/RV3v294OlCwGlRMqp40q9dd+RYHxUA92PO MokKmOyw6HOR8/YLxZtcSQ==; Date: Sat, 13 Apr 2024 10:02:24 +0300 Message-Id: <86wmp1rbi7.fsf@gnu.org> From: Eli Zaretskii To: Andrew Burgess Cc: gdb-patches@sourceware.org In-Reply-To: <87frvq43gj.fsf@redhat.com> (message from Andrew Burgess on Fri, 12 Apr 2024 23:32:28 +0100) Subject: Re: [PATCH] gdb/doc: use silent-rules.mk in the Makefile References: <09d4a16a33cf31f558a8982075800b113ed4a14e.1712940998.git.aburgess@redhat.com> <868r1isaad.fsf@gnu.org> <87frvq43gj.fsf@redhat.com> X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > From: Andrew Burgess > Cc: gdb-patches@sourceware.org > Date: Fri, 12 Apr 2024 23:32:28 +0100 > > Eli Zaretskii 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?