linux-kbuild.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Goncharov <dgoncharov@users.sf.net>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org
Subject: Re: Port silent mode detection to future gnu make.
Date: Tue, 29 Nov 2022 12:27:38 -0500	[thread overview]
Message-ID: <CAG+Z0CusEYVCMP9LSOQ3Cahr--DHwVOxDLQwgVed3T9hdLBw6w@mail.gmail.com> (raw)
In-Reply-To: <CAK7LNAQn248OsEGXCRFNURt7VC6eNfu-EEtphdtw9uNJPD_16Q@mail.gmail.com>

On Tue, Nov 29, 2022 at 1:22 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> Kbuild is already having an issue in the -s detection.
> $ export MAKEFLAGS=-I/usr/local/mk
>  or
> $ export MAKEFLAGS=-Orecurse

i am not concerned about these use cases. This code in question fails
to handle the use case of MAKEFALGS in env and apparently this does
not bother anyone, otherwise this code would already be fixed.  My
concern is that the change, that we introduced to make, won't cause a
regression to those of us who specify -s, once the users migrate to
the new make.
However, the fix will help the MAKEFLAGS-in-env use case, as well.


> Commit 77881d228103 ("Ensure that MAKEFLAGS is set when invoking $(shell ...)")
> is the commit that caused a change.

The whole sequence of events is the following

1. commit 98da874c43035a490cdca81331724f233a3d0c9a [SV 10593] Export
variables to $(shell ...) commands
This allowed make variables to be exported to $(shell) at parse time.

2. Then a user opened https://savannah.gnu.org/bugs/?63347 and
(correctly) argued that the behavior is inconsistent. The
inconsistency was caused by MAKEFLAGS lacking command line variable
definitions until build time.

3.  commit dc2d963989b96161472b2cd38cef5d1f4851ea34 [SV 63347] Always
add command line variable assignments to MAKEFLAGS
This adds command line variable definitions to MAKEFLAGS at parse time.




> Please send v2 with $(firstword) and updated commit log.
> Also, add this tag:
> Link: https://lists.gnu.org/archive/html/bug-make/2022-11/msg00190.html

Done.

regards, Dmitry

      reply	other threads:[~2022-11-29 17:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAG+Z0CviRhBQqWfAPFDht+mWUJf4azPSZgOV0jrur_YSP23__A@mail.gmail.com>
2022-11-27  5:46 ` Port silent mode detection to future gnu make Masahiro Yamada
2022-11-27 15:36   ` Dmitry Goncharov
2022-11-29  3:00   ` Dmitry Goncharov
2022-11-29  6:18     ` Masahiro Yamada
2022-11-29 17:27       ` Dmitry Goncharov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAG+Z0CusEYVCMP9LSOQ3Cahr--DHwVOxDLQwgVed3T9hdLBw6w@mail.gmail.com \
    --to=dgoncharov@users.sf.net \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).