From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 68QQNbBn7l9PMgAAWB0awg (envelope-from ) for ; Thu, 31 Dec 2020 19:07:12 -0500 Received: by simark.ca (Postfix, from userid 112) id CAF471F0AA; Thu, 31 Dec 2020 19:07:12 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7896F1E552 for ; Thu, 31 Dec 2020 19:07:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C0F363861969; Fri, 1 Jan 2021 00:07:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C0F363861969 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1609459631; bh=MuULnkf+t492zRl4oyRdyy+SVOY4ywDk49D8cUNdQBI=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=bWw4GDALiY/iYOrJMhMNHeKFpjOfJQwjanbbmLhD1P1PLWS1d2tvWSwm3RW9fhotV HcDXkenl77APZ3yW8560/oM7ynGQmWfFVWf0nozEnvL39v+9D1pDcBvC85IDVU4Cx/ PeinRycrsnklJMAC/X2uAoY5E2cN+Ql0/LMUdxlo= Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id B982E3857815; Fri, 1 Jan 2021 00:07:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B982E3857815 Received: by mail-oi1-x231.google.com with SMTP id w124so23242929oia.6; Thu, 31 Dec 2020 16:07:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MuULnkf+t492zRl4oyRdyy+SVOY4ywDk49D8cUNdQBI=; b=fFqzaWa8G3M/0Z0d1J/KxqcLO2MDJqnPW/iEHpIPiXGRdq8CKI2our0cD+30DDdN+B NPPp4OJkw5gi8N/D4v92ps9ly9kXFwU3BRI104C/ldUEi6oeCl5TNvlgzkHuULxEKITG vlZm8KqDAR1zhhj9/jbAP3UyofFdH3WGxkK3uUCQMrbMYHYwnwzYsGfeYoTSN/L5cx40 lntaaRAi1GjghjzylcifSQUbujXCT9p9VMUnIk6ykCQ1w0zNrw5sDCLCsjVHUL4+ioj/ 8PbuwOjrq9kd2KCJMbjtMwJ7T0K169FSunnfrH7X1K6KvEKoqXGoTSXXZ4KodJr63IH7 OXdw== X-Gm-Message-State: AOAM532+3h9/g4eMbF+ZxlpHcLw20d/3PTaTgSWcW3bHUlnr7dkViKLU KbQrTZ21YTngczelbhy7ncTVfaiZ2WIaxTTDspajailh X-Google-Smtp-Source: ABdhPJwR9F8y01Q+dwmG+KpBVVlg6pk5vGCcmmOCP1/HJFOm2n10jIlYnP9vXVC/XHJJzHpCdqnXolPVAB5DDWHrcq4= X-Received: by 2002:aca:f5d3:: with SMTP id t202mr9446129oih.25.1609459628212; Thu, 31 Dec 2020 16:07:08 -0800 (PST) MIME-Version: 1.0 References: <20201219181036.178248-1-hjl.tools@gmail.com> <20201219181036.178248-6-hjl.tools@gmail.com> In-Reply-To: Date: Thu, 31 Dec 2020 16:06:32 -0800 Message-ID: Subject: Re: V3 [PATCH 5/5] gnulib: Support variables from the top level Makefile To: Joseph Myers Content-Type: text/plain; charset="UTF-8" X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "H.J. Lu via Gdb-patches" Reply-To: "H.J. Lu" Cc: Matthias Klose , GCC Patches , Binutils , GDB Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On Thu, Dec 31, 2020 at 3:50 PM Joseph Myers wrote: > > On Sat, 19 Dec 2020, H.J. Lu via Gcc-patches wrote: > > > Work around what appears to be a GNU make bug handling MAKEFLAGS > > values defined in terms of make variables, as is the case for CC and > > friends when we are called from the top level Makefile. > > This description, and the comment in Makefile.am repeating it, is rather > unhelpful as it provides no way for a reader to know what the supposed bug > is. Reviewers need to be able to work out whether the proposed workaround > is correct or the right approach for working around the bug. Maintainers > in future need to be able to tell what the bug is. So the comment needs > to explain what the bug is and give a reference to a report for the bug in > the GNU make bug tracker, so that subsequent maintainers can look at that > bug to tell if the workaround is still needed at all. > I just copied the same workaround from other directories in GCC. -- H.J.