From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2a.google.com (mail-oa1-x2a.google.com [IPv6:2001:4860:4864:20::2a]) by sourceware.org (Postfix) with ESMTPS id 455C73853D66 for ; Wed, 30 Nov 2022 22:23:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 455C73853D66 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-oa1-x2a.google.com with SMTP id 586e51a60fabf-1432a5f6468so105875fac.12 for ; Wed, 30 Nov 2022 14:23:17 -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=GkkN9V9sdVuo/L9E2/wKkpbMCG7cL3et5ucNneLqMJk=; b=OcTWrURmZpg1T+8+Sju1ofHBkWSHzagvAG2piVG+sW7wq41vg4rF0tIsiFt7ctRx1G V2T7wBXkSSxZvTlZsEOn8Z7C6rDm4YbMYT66KcXK1V0BiffJEaMfATpBAn77UKzABUf6 gMjZcMRSE3Uq8X7D6h8KvRLxgnYKtYO1uSZT3YpafpNDicSQKbsPAGSOiY8lcs/jFmbK kQHDzVYqAAjGr7cMp5GWZAJzWUsAvjKNeR++RyTH0c5Cvh2HhBVOUHUJY/jP/O+ZZr52 iP/kqaXuUuM+U4JqxG9CGnjVXsSMJEs8N+bP3si1wf0cVIAruHuVD/1iiDQ18McJWWrg R6PQ== 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=GkkN9V9sdVuo/L9E2/wKkpbMCG7cL3et5ucNneLqMJk=; b=Vc9Be7bKB/4qp5p9IQYdRaPJc3Se5LOjnNT8f/jUD3K8hE7mk9nBQ5t88qId9/FesB toEE0XDcRlGxT6Kohfi3C5l9p7BRsOBwS+lyKXzI+0ftYkvbN6jQgzPUMc/BWtqxAl7r a3SxC4ojHroGHoRKPnH+p/kj7UAc3T6DonPm0RHTtT6lkM8xSxQjuQ304i3ZWSz+bK07 XkoYY1HjD8qUToyf/nzaHNs67MxM1GTaXo9rJTFcrMd5T0cmfTz9FT6FaTo7+ecP3bK2 smd2mQb5DHMDJ3BC3UghOALLFH+yNWqBZuqUkl24cC+461gYMSjgQGMkSer2pLzCXWY2 MnSg== X-Gm-Message-State: ANoB5pmr34TC4BW+T6OxsTxWHMT60nC2oO4mp6E+D8/YQolXEQ7DmGAe yvoNBbYMfEU5tay5gh0tCtdg/raB+a+xJhB9wb/4OVVIzY0= X-Google-Smtp-Source: AA0mqf7nVTQY8NwrbzAPlXwC7K0ZCKAc7g5HiqAZErEv4BNgSX8ia8pmCD0w1TfZTT10y0fB/UzhxNOCW+KZZB+VuJU= X-Received: by 2002:a05:6871:4501:b0:13c:5da4:7229 with SMTP id nj1-20020a056871450100b0013c5da47229mr29390293oab.266.1669846996611; Wed, 30 Nov 2022 14:23:16 -0800 (PST) MIME-Version: 1.0 References: <20221122181927.251937-1-hjl.tools@gmail.com> <6a5d4918-919a-8b6b-822b-17ce38488629@suse.com> <63e51eee-e9f4-5332-d69e-feca3421553b@suse.com> In-Reply-To: <63e51eee-e9f4-5332-d69e-feca3421553b@suse.com> From: "H.J. Lu" Date: Wed, 30 Nov 2022 14:22:40 -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=-3016.9 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 10:58 PM Jan Beulich wrote: > > On 30.11.2022 01:06, H.J. Lu wrote: > > On Tue, Nov 29, 2022 at 11:38 AM H.J. Lu wrote: > >> > >> 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. > > > > There are > > > > bfd/Makefile.in: ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) > > $$local_target) \ > > binutils/Makefile.in: ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) > > $$local_target) \ > > gas/Makefile.in: ($(am__cd) $$subdir && $(MAKE) $(AM_MAKEFLAGS) > > $$local_target) \ > > I'm glad you spotted this yourself - I was just about to point out > that my concern isn't only a theoretical one, because of the > generated makefiles we use. You don't draw any conclusion though: > Are you willing to accept my approach, specifically reworked to > account for an extra request of yours? Or are you meaning to make > another attempt yourself, avoiding the undue make recursion? > Calling $(MAKE) in Makefile is very normal in binutils-gdb. I don't see anything wrong with my approach. I prefer my approach. -- H.J.