From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76981 invoked by alias); 17 May 2017 14:03:27 -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 76612 invoked by uid 89); 17 May 2017 14:03:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-14.8 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=disagree, Hx-languages-length:2826 X-HELO: mail-wm0-f46.google.com Received: from mail-wm0-f46.google.com (HELO mail-wm0-f46.google.com) (74.125.82.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 May 2017 14:03:24 +0000 Received: by mail-wm0-f46.google.com with SMTP id b84so166443456wmh.0 for ; Wed, 17 May 2017 07:03:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=wrxIijQsRt28satbPF+7MMqDrmYXhLr8Ge4VJQqjxsk=; b=D7eovy2nepuWWhxYPHsk95Bs6EK4miFKEInAwotgXfqzVG40RoZ0mEJD9pUJcvDjhr Vka0JgEGdib9+WKfPPvoq/R12GugvykqUgtnTJ+eEQ7cx8OEdLIdENdiYKvwydMcCLI+ bC0v9AcDvpdbwMp17gg0tSnv8nAVFvmmaMTOzNwHeJmwIQu4yOJnE3tQ1lwLatuQu1ds PVtLseSavnNEAeEDUtu9aWtXObYXujRYboSu+4mVkbtN/hAna0zHMyNbAM+EK5XC1HOL ulwTpX2mub/xtb8xlAcM4dSvQI0qNA/o3gQ8YNaOh7yeXvVfTYr6BXD8d5Rp+UpiWj64 5lgA== X-Gm-Message-State: AODbwcC3LL83VS6c9b35YVtRWQeIapWvHBS2I5D+1FpexMQpubL/Ynya RlWxddCaAf7lQCymCnFHiA== X-Received: by 10.28.66.212 with SMTP id k81mr10047324wmi.132.1495029805557; Wed, 17 May 2017 07:03:25 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id j128sm4355670wmd.12.2017.05.17.07.03.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2017 07:03:24 -0700 (PDT) Subject: Re: [PATCH v2 1/2] Introduce "gdb/configure.nat" (and delete "gdb/config/*/*.mh" files) To: Sergio Durigan Junior 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> <87mvaqulnp.fsf@redhat.com> Cc: GDB Patches , Simon Marchi , John Baldwin From: Pedro Alves Message-ID: Date: Wed, 17 May 2017 14:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87mvaqulnp.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2017-05/txt/msg00392.txt.bz2 On 05/06/2017 03:04 PM, Sergio Durigan Junior wrote: > 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. And I see yours now. > But one could also argue that > there's not actual fragment there, since we just have variables being > AC_SUBST'ed. Right, that's not what is usually called a fragment. Note that Makefile "fragments" are a well known term in the GNU toolchain's build machinery . See e.g., old GCC docs describing their fragment files: https://gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_19.html > >>> 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. :-) Note this is described in the internal's manual urls I pointed at before: https://sourceware.org/gdb/wiki/Internals%20Adding-a-New-Host https://sourceware.org/gdb/wiki/Internals%20Native-Debugging "Maintainer’s note: The .mh suffix is because this file originally contained Makefile fragments for hosting GDB on machine xyz. While the file is no longer used for this purpose, the .mh suffix remains. Perhaps someone will eventually rename these fragments so that they have a .mn suffix." These pages are now in need of an update. Thanks, Pedro Alves