From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 603473858D20 for ; Tue, 29 Nov 2022 19:39:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 603473858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x22c.google.com with SMTP id n205so16415992oib.1 for ; Tue, 29 Nov 2022 11:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SOBoV9sUSSk6pRhtsJwTWdIpv7OWAfY76FSY1bUWquA=; b=HD68rpcvZoXAhdQg1VU1TXF+lrmW6oMZWYiGRpadrDu0VEsHC+B5l8Cn3QQziGh5Nx WtDwNaw5hV22Hie8dcgwpr1yi8oRUefq0IftMOoJcs35M+xRnBQZvqpEqgarWua4voP8 CxTQpHD6fYm0LYqsnzemLlUhuHfCGB0IEAgor2iwM2KdKyETVoSUCl5DNXa2f4xTNZsn PCEwJmZPftjoXrxU34X9346DktTV2YWEq2S+fYW/oSC/EXV5WWKj3v4nnr5GjfmZdMf5 ABMldFZ2GDbwyQ68eyKOunVktUqWcoETuHu+SuqgoAHZtxUUuXxOsbvIvqv8e0ugXHU5 2BMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SOBoV9sUSSk6pRhtsJwTWdIpv7OWAfY76FSY1bUWquA=; b=Q+OkMDT1y+yeHR5/2HM70hUsKOsZXkmGe/lfVDewbzs081lsyinNWQIY4uebnPc7rb JmyptjGkPhUb6cJ63lFV9R6ya9C01/DBVXDRwe3ufABV1luNlgRrNx/cVaGOehzgSuQY ImRkUkEsIgkI3Y0QelkCHlTIrHoeeT3hWlYBqU5GnjYb/Qp9nfn7lbZgpqfmfOTXRIln m5/WNK0USPbUeNRpObvl+++Ii2jNUmRnGjIh/rpkA1jVJG3g8/lFwJSc5bqIVaHaDy7/ 4BYyWFYLgRPlCCGMlCDNkaxVj27YHLhY+ADq1iPH2ELMfQFIt7T6p6xWtjj9Yqbvu21m kHkQ== X-Gm-Message-State: ANoB5pnsG/NCLgPmG1EJdXoqp+1zOK+UP7l+UZZfURBEVn/aKWFk1Qzt ycMpN1vbQ2VkG8kWXgWWmPXXa2lzDrtyy7KyZlY= X-Google-Smtp-Source: AA0mqf7clnvvfMmn5I+kqrF2xxKdO7cw61U+VDVtKbOL7XiwhZvuW7xU7mkZvg7ETFafC3NoZaH5TTygSgfzQxwFqSI= X-Received: by 2002:a05:6808:1309:b0:359:d97b:3f6f with SMTP id y9-20020a056808130900b00359d97b3f6fmr20991360oiv.298.1669750742568; Tue, 29 Nov 2022 11:39:02 -0800 (PST) MIME-Version: 1.0 References: <20221122181927.251937-1-hjl.tools@gmail.com> <6a5d4918-919a-8b6b-822b-17ce38488629@suse.com> In-Reply-To: From: "H.J. Lu" Date: Tue, 29 Nov 2022 11:38:26 -0800 Message-ID: Subject: Re: [PATCH v2] x86: Remove libopcodes dependency To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On Tue, Nov 29, 2022 at 1:22 AM Jan Beulich wrote: > > On 29.11.2022 00:49, H.J. Lu wrote: > > On Thu, Nov 24, 2022 at 2:19 AM Jan Beulich wrote: > >> On 22.11.2022 19:19, H.J. Lu wrote: > >>> --- a/gas/Makefile.am > >>> +++ b/gas/Makefile.am > >>> @@ -446,6 +446,12 @@ development.exp: $(BFDDIR)/development.sh > >>> $(EGREP) "(development|experimental)=" $(BFDDIR)/development.sh \ > >>> | $(AWK) -F= '{ print "set " $$1 " " $$2 }' > $@ > >>> > >>> +$(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: \ > >>> + @MAINT@ $(srcdir)/../opcodes/i386-opc.tbl \ > >>> + $(srcdir)/../opcodes/i386-reg.tbl \ > >>> + $(srcdir)/../opcodes/i386-opc.h > >>> + cd ../opcodes; make gen-i386-tbl > >> > >> I've made a patch to gas/Makefile.am as you have requested in reply to > >> my series. I will want to put that through some more testing, so I will > >> submit a v3 of that only a little later (and of course only unless you > >> submit a v2 of your patch earlier that I would also end up being okay > >> with). In the course of doing so I noticed a few more issues with your > >> change: > >> > >> For one I don't think you can put @MAINT@ on a continued line, as the > >> line continuation might then be hidden when @MAINT@ expands to #. The > >> list of dependencies wants expressing via a variable, which would then > >> be used immediately after @MAINT@ without any line continuation > >> following. > > > > Fixed. > > No, the same problem is still there. You either need to use a very long > line, or you need to introduce a variable holding the list of prereqs, > like I've done in my series. I got $(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: $(srcdir)/../opcodes/i386-opc.tbl \ $(srcdir)/../opcodes/i386-reg.tbl \ $(srcdir)/../opcodes/i386-opc.h \ $(srcdir)/../opcodes/i386-gen.c $(MAKE) -C ../opcodes gen-i386-tbl and $(srcdir)/../opcodes/i386-init.h $(srcdir)/../opcodes/i386-tbl.h: # $(srcdir)/../opcodes/i386-opc.tbl \ $(srcdir)/../opcodes/i386-reg.tbl \ $(srcdir)/../opcodes/i386-opc.h \ $(srcdir)/../opcodes/i386-gen.c $(MAKE) -C ../opcodes gen-i386-tbl I didn't run into any problems. > >> And then your rule / dependency won't be enough on a "maintainer-clean" > >> tree, i.e. when the generated headers aren't there at all, and when > >> config/.deps/tc-i386.Po is still empty. In that case nothing would > >> trigger their generation; an explicit dependency of config/tc-i386.o on > >> these headers needs adding here. > > > > Fixed. > > > >> Finally you're missing a dependency of the generated headers on > >> i386-gen.c. > > > > They have a dependency on i386-gen which depends on i386-gen.c. > > In opcodes/, yes, but talk was about the rule in gas/. Yet despite > your comment above I see that you've added the missing dependency. > > > Here is the v2 patch. > > As said in reply to v1 - my objection to this particular use of make > recursion remains. The gen-i386-tbl rule doesn't touch any files used by libopcodes. > I also continue to be irritated by you specifically having asked me > to further split my series, when you do everything in a single patch. My patch is relatively small and it does only one thing. > One further request at least for consideration: In my v3 I've moved > the inclusion of opcodes/i386-tbl.h quite a bit further down in > tc-i386.c, as I think it's preferable that way (not introducing the > static arrays earlier than necessary). Does it make any differences? -- H.J.