From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id A19C33858D35 for ; Tue, 16 Apr 2024 07:48:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A19C33858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A19C33858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713253689; cv=none; b=MODHf1123267fI8e20bDZDwIcv5qE/+mwRloLJuW52EuMJ4+LzGwqBFz5UoZv1BbEpHpuEJWzqrvqgmI082qEPfGmHwyTKq16IG+L8hb4R+L1tBzqSMQeSzeueicIgA2yj1nuAyLa3MKIF0zmZytJXPrLYLewk0Y/E9xaQFEOcU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713253689; c=relaxed/simple; bh=TuG5tUimuxHtSs+TSQw4WKJ1dWig/wEM+HmlMF6Ttg0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=jrC9TWsR3w0FIlghRtHzeEJcoKrXKrIPDE8Yg3slHTCVzUqixiM/PpWHaXXTwSA9/QavECZOMzaAG+ZGdAQCWLb4OngxiB01y41Vu92W/FUhW/PxJ2PCEXb2X4b5O7EgPkcdo43R59+FD2omNjFb3JxNdmSOfcCWVcwNDn4x14s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713253686; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nVn02z4N+EbR4K6mvJrY6Dr4Dtkzpn9CjtMYack8gSE=; b=cSiLkPeTyaA4pXdM9U0EzebABJxS/9WBQhjBiBw1nlNlbHLLArr5BgRkJQf0nsVjLEFMXr 3f6A19YdkRleq0YCHCFnfZj6Qhtk4WQ1wMWjjXZNI7Q0OpqT06Rq8NIFLTOFQ/NchSes0I tD1xOyQSg+sAQ4gt3fDeisZkBOUB+tQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-499-kOL4gdhUMuyZdRxqX9i-xw-1; Tue, 16 Apr 2024 03:48:04 -0400 X-MC-Unique: kOL4gdhUMuyZdRxqX9i-xw-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-41663c713b7so24658075e9.0 for ; Tue, 16 Apr 2024 00:48:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713253683; x=1713858483; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nVn02z4N+EbR4K6mvJrY6Dr4Dtkzpn9CjtMYack8gSE=; b=BAs+UwADUgJYlc+aq4MKnwfhCeiZ1T6P9+Rtal8Cc2MjJgNxjKllif+vk0ye37Y0qV hKx/uZKuRBx1+yPruGiG7BVKR2Oyq2g7rurywPA1z1Gd9lBi+NsX47NbgUd/QFpkO3q3 BQx2v2qhMQDVsmfYfA8/hjC1DDGCHl9Gcp4huwhfsGb+KMD5qeCPJN7RYggDr202fwo5 j/rdnKDMTljTkVmSBZJ7S8SjvNRZdR/9g+ErEcp8sEUUImmXX5Qun+Me8VTMNBDCWOlR f5+nfcwrfim+/3tUYhjACqPQOOVEfJBZx27fBNrjhtulWoBxr20b/K7gr0vr4fOR6k9k gDLw== X-Gm-Message-State: AOJu0YxQivA1SfD6couxvCxGBkEYO1/OXesiU86nwT7Sqp5TfllBI9Il 41t8f8t/G9KwyTlMdBpE2MiH+FXP51PRARLrzOng4p1grH1N6qVzoqP1sBOKTUUEv8V3WxJJBDn aPjAeHPk5v74aX2F4KDSg+UxjsBGwTCyXu/hFoqyJ3VmvQi0VXPvM7meIQJ8= X-Received: by 2002:a7b:c3d6:0:b0:418:91ae:befc with SMTP id t22-20020a7bc3d6000000b0041891aebefcmr950300wmj.0.1713253683467; Tue, 16 Apr 2024 00:48:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEEVmCxpUXKNlpRS70JU/epOw87r+Oo7PlP1aWKGTJPyfk4JrfzIL8HrUDXFsIBd9u+o0LFaw== X-Received: by 2002:a7b:c3d6:0:b0:418:91ae:befc with SMTP id t22-20020a7bc3d6000000b0041891aebefcmr950271wmj.0.1713253682701; Tue, 16 Apr 2024 00:48:02 -0700 (PDT) Received: from localhost (185.223.159.143.dyn.plus.net. [143.159.223.185]) by smtp.gmail.com with ESMTPSA id v17-20020a05600c471100b00417ee784fcasm16705858wmo.45.2024.04.16.00.48.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Apr 2024 00:48:02 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/doc: use silent-rules.mk in the Makefile In-Reply-To: <81120371-21de-45ab-8ea7-bd8146a7f7a3@simark.ca> References: <09d4a16a33cf31f558a8982075800b113ed4a14e.1712940998.git.aburgess@redhat.com> <868r1isaad.fsf@gnu.org> <87frvq43gj.fsf@redhat.com> <86wmp1rbi7.fsf@gnu.org> <874jc2ivcb.fsf@redhat.com> <81120371-21de-45ab-8ea7-bd8146a7f7a3@simark.ca> Date: Tue, 16 Apr 2024 08:48:01 +0100 Message-ID: <87v84hhhou.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Simon Marchi writes: > On 4/15/24 9:55 AM, Andrew Burgess wrote: >> Eli Zaretskii writes: >>> So my preference would be for having the above emit something like the >>> below instead >>> >>> TEXI2POD gdb.pod >>> POD2MAN1 gdb.1 >> >> That one's harder. The target information comes from make's $@ >> variable, so it's easy enough to do: >> >> TEXI2POD gdb.1 >> POD2MAN gdb.1 >> >> which isn't exactly what you asked for. > > Could you split the rule in two? One rule generating gdb.pod and one > rule generating gdb.1. > > I personally think the original output from Andrew's patch is fine. In > the silent mode, all I need to know is that make is currently working on > getting gdb.1 generated. The intermediary gdb.pod file is an > implementation detail of the rule. If I want to see it, then I'll use > `make V=1`. I agree. > But if it makes everyone happy, I don't mind if we split the rule in > two. Smaller and simpler rules are easier to understand. I didn't really want to split the rule as the .pod really is an intermediate step: $(SILENCE) touch $@ -$(ECHO_TEXI2POD) $(TEXI2POD) $(MANCONF) -Dgdb < $(srcdir)/gdb.texinfo > gdb.pod -$(ECHO_TEXI2MAN) ($(POD2MAN1) gdb.pod | sed -e '/^.if n .na/d' > $@.T$$$$ && \ mv -f $@.T$$$$ $@) || (rm -f $@.T$$$$ && exit 1) $(SILENCE) rm -f gdb.pod We create the .pod and then consume it, before finally deleting it. If the rule was split then we'd end up creating the .pod in one rule before deleting it in another, which didn't seem great. But if you're happy with that change then I can split the rule. Thanks, Andrew