From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66521 invoked by alias); 6 May 2017 14:04:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 66199 invoked by uid 89); 6 May 2017 14:04:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=ahhh, reality X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 06 May 2017 14:04:10 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3C2BC81235; Sat, 6 May 2017 14:04:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3C2BC81235 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=sergiodj@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 3C2BC81235 Received: from localhost (unused-10-15-17-193.yyz.redhat.com [10.15.17.193]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E39825C542; Sat, 6 May 2017 14:04:10 +0000 (UTC) From: Sergio Durigan Junior To: Pedro Alves Cc: GDB Patches , Simon Marchi , John Baldwin Subject: Re: [PATCH v2 1/2] Introduce "gdb/configure.nat" (and delete "gdb/config/*/*.mh" files) References: <20170425202309.15771-1-sergiodj@redhat.com> <20170503034931.4515-1-sergiodj@redhat.com> <20170503034931.4515-2-sergiodj@redhat.com> <9d941b3b-1b16-3c17-6cae-11940ade7477@redhat.com> <87pofoymyk.fsf@redhat.com> <91244564-2cfa-4306-8055-f26a109ecd72@redhat.com> Date: Sat, 06 May 2017 14:04:00 -0000 In-Reply-To: <91244564-2cfa-4306-8055-f26a109ecd72@redhat.com> (Pedro Alves's message of "Fri, 5 May 2017 10:41:54 +0100") Message-ID: <87mvaqulnp.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00162.txt.bz2 On Friday, May 05 2017, Pedro Alves wrote: >>>> diff --git a/gdb/config/i386/i386gnu.mh b/gdb/config/i386/i386gnu-extra.mh >>>> similarity index 58% >>>> rename from gdb/config/i386/i386gnu.mh >>>> rename to gdb/config/i386/i386gnu-extra.mh >>> >>> Why the "extra" rename ? If anything, I'd expect i386gnu.mh -> i386gnu.mn? >> >> git showed this as a rename, but it's really a new file. > > That's kind of stretching it. :-) Well, my intention from the beginning was to introduce this as a new file. I'm not stretching it my intention :-). >> i386gnu.mh is >> gone, like every other previous *.mh file. Instead of using the old >> name, I decided to add the "-extra" suffix to make it explicit that the >> file contains only extra definitions, and is not the only thing taken >> into account for this native target. > > I find the "extra" redundant -- the way I see it, some targets have a > makefile fragment file that needs to be glued into the Makefile, > others don't. There's no "main fragment, and then maybe some other/extra ones". OK, I see your rationale now. In my previous understanding, the main fragment was being generated from configure.nat, which is just a copy-and-paste from the old *.mh files. But one could also argue that there's not actual fragment there, since we just have variables being AC_SUBST'ed. >> I initially disagree with your proposal to rename it to i386gnu.mn, so >> I'm keeping it this way. > > Why do you disagree? ".mh" obviously meant "makefile + host", > but the fragment file is now described as being about the > native target. Hence, "makefile + native => .mn". Ahhh. You're not going to believe it, but until now I was not linking the fact that ".mh" meant "makefile + host". I obviously agree that the new extension should be .mn. > I don't understand the rationale for renaming the file, saying it > is a native target fragment, but _still_ calling it ".mh". > So, I'd understand either not bothering to change the file name > at all, or if renaming it, then giving it a name that matches reality. > >> Please let me know if you really thing the >> "-extra" suffix shouldn't be there, and I can remove it. > > I really think the -extra suffix shouldn't be there. Fair enough. Sorry about the confusion; I'll remove the -extra and use .mn as the extension. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/