From: Roland Hieber <rohieb@rohieb.name>
To: ptxdist@pengutronix.de
Cc: Roland Hieber <rohieb@rohieb.name>
Subject: [ptxdist] [PATCH] Toplevel: fix detection of -n / --dry-run option
Date: Mon, 10 Dec 2018 00:24:42 +0100 [thread overview]
Message-ID: <20181209232442.16001-1-rohieb@rohieb.name> (raw)
$(filter n,$(MAKEFLAGS)) will be empty if make is called with any
additional parameters. For example, with `make -s -n`, MAKEFLAGS will
contain "sn", which will not match the pattern "n".
The following way is inspired by kernel commit 6f0fa58e459642b169, which
tried to do the same for the -s / --silent option (although support for
make 3.x is probably not important to us):
kbuild: simplify silent build (-s) detection
This allows to detect -s (--silent) option without checking GNU Make
version.
As commit e36aaea28972 ("kbuild: Fix silent builds with make-4")
pointed out, GNU Make 4.x changed the way/order it presents the
command line options into MAKEFLAGS.
In Make 3.8x, 's' is always the first in a group of short options.
The group may be prefixed with '-' in some cases.
In Make 4.x, 's' is always the last in a group of short options.
As commit e6ac89fabd03 ("kbuild: Correctly deal with make options
which contain an 's'") addressed, we also need to deal with long
options that contain 's', like --warn-undefined-variables.
Test cases:
[1] command line input: make --silent
-> MAKEFLAGS for Make 3.8x: s
-> MAKEFLAGS for Make 4.x : s
[2] command line input: make -srR
-> MAKEFLAGS for Make 3.8x: sRr
-> MAKEFLAGS for Make 4.x : rRs
[3] command line input: make -s -rR --warn-undefined-variables
-> MAKEFLAGS for Make 3.8x: --warn-undefined-variables -sRr
-> MAKEFLAGS for Make 4.x : rRs --warn-undefined-variables
My idea to cater to all the cases more easily is to filter out long
options (--%), then search 's' with $(findstring ...). This way will
be more future-proof even if future versions of Make put 's' in the
middle of the group.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Fixes: a0b8075391cfeb324f60e42482b1c34f "ptxdist: add --progress option"
Signed-off-by: Roland Hieber <rohieb@rohieb.name>
---
rules/other/Toplevel.make | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules/other/Toplevel.make b/rules/other/Toplevel.make
index 5d81c7504..7e850e233 100644
--- a/rules/other/Toplevel.make
+++ b/rules/other/Toplevel.make
@@ -3,7 +3,7 @@
# Copyright (C) 2002-2009 by The PTXdist Team - See CREDITS for Details
#
-ifneq ($(filter n,$(MAKEFLAGS)),)
+ifneq ($(findstring n,$(filter-out --%,$(MAKEFLAGS))),)
# make sure recursive calls do nothing for --dry-run
MAKE=true
SHELL=true
--
2.19.2
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
reply other threads:[~2018-12-09 23:25 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20181209232442.16001-1-rohieb@rohieb.name \
--to=rohieb@rohieb.name \
--cc=ptxdist@pengutronix.de \
/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