From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id 176493855173 for ; Mon, 28 Nov 2022 23:43:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 176493855173 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-x22e.google.com with SMTP id l127so13431995oia.8 for ; Mon, 28 Nov 2022 15:43:46 -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=6TN379698acP2YQZEV14yisVMurfi9T8O7M7vjSb/8Q=; b=L/toKLjHSZaawsqvlI7e4wC2v24yVxbB1+py4HByQskF17o+co7cf6vLeZ2xKAeQiR 67G5/8EiRBg45vufbsCuzdYGcmIh5oLjLFSv2LrA+2eLYgIQzjV9xnJxahK+Ms8ehj+M /7XnjNhpfMlJ+P3PFEAQhgk3wItamq4rpkJ8CCksjDJy9p/H/EaO/M3QuK2bKKzI5R6M fwG8KQIhdyWl9c40U9eeHlb46Il757Y/6r2Mr1acBHNEwBJjZS2r5XP45qern+LtqGNT XN5J0F+KzwgQabQoDE3Ul+otr11DoNTWvsI/xS+dtLe1UEWqlHYfxt6lfeZn0SUJOxIc Zavg== 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=6TN379698acP2YQZEV14yisVMurfi9T8O7M7vjSb/8Q=; b=7uqN9UQC7m09Vpq8Kk1PzV3EwUWlmI+UPa/1veLrK81WI+dqy5XFe/yomBUbGtSbbe nxj3i7Rj4Hb6WlebYEJHDP5TimkiT6SwuuCoiwocLXMlAegCO9hRXwFob4Fy3IUfAHnK tRX/CILymtDWUdxsf1yCgXdyYBV6BK+HTv1R8h64AcUBMGspsSKRTrTxX1kZt6iM8FSG 8q3S6peEqQMcpSK+UH2tUz1Wq5PnKavYwxVRNBp1t8VMaH31CDAImrY0S9QLQAuyWaAe eYX8R7Pwiez1iyZiJnyKu0TwF7ifWF3+ibT7fhUHz+6Y30AAtbcpsbEErP47Xu4/u43+ tAgQ== X-Gm-Message-State: ANoB5pk77zy+WuQNC5VKlGz8vQuj5tfEi++WTN3QI7w0RApXbWPNtT3N DCqZOSPWt+O4DqWs9w1sURDOOOe2du/TfdtJCMU= X-Google-Smtp-Source: AA0mqf498B2qP7HP9xB/kCbVW+Sa4no/6QXxNNdOAfwbfXJYnRja4ovCRGJFE8pp3O4fqhv7Rp0f1Z/usdXDFA/8iXo= X-Received: by 2002:aca:bc87:0:b0:35b:1f92:e4ff with SMTP id m129-20020acabc87000000b0035b1f92e4ffmr18153382oif.266.1669679025313; Mon, 28 Nov 2022 15:43:45 -0800 (PST) MIME-Version: 1.0 References: <20221122181927.251937-1-hjl.tools@gmail.com> <4d995c45-7e4c-4f66-5459-1b1c33aa4dd8@suse.com> In-Reply-To: <4d995c45-7e4c-4f66-5459-1b1c33aa4dd8@suse.com> From: "H.J. Lu" Date: Mon, 28 Nov 2022 15:43:09 -0800 Message-ID: Subject: Re: [PATCH] x86: Remove libopcodes dependency To: Jan Beulich Cc: binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.6 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 Wed, Nov 23, 2022 at 12:36 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 > > This recursing into a different directory (and then even using "cd" and > "make" instead of "$(MAKE) -C") is what I have specifically avoided in > my patches. This is deemed an anti-pattern by many people: If you > consider running make in just gas/ is an okay thing to do, then running > make in just opcodes/ is, too. Yet with such a rule doing so in parallel > can result in strange collisions and likely partially broken files. "make" in opcodes won't regenerate these header files. As far as make dependency is concerned, $(MAKE) -C ../opcodes gen-i386-tbl is like other programs. > Therefore with my general maintainer hat on I object to such an approach. > > If you really want to generate the files from gas/, then you should do > so there, i.e. also going as far as building i386-gen there. Once > again I did consider doing to, but deemed it awkward: Even if we don't > use libopcodes.{a,so} anymore, I think the opcode table processing > would better remain in opcodes/ - we'd use that library no longer as > a binary but as a (generated) source code one. If you think differently, > I wouldn't object to you following this alternative approach. > > As a formal remark: In the description I would expect to be credited at > least for recognizing the opportunity; really you've re-used some of Will do. > what I've had in my patches, irrespective of you perhaps having done > things from scratch (and having spotted/corrected an oversight of mine, > which I was about to submit v3 of my series for, but which now I will > wait with until the above is settled - sadly meaning yet further delays > for the growing pile of other work I have pending on top). > -- H.J.