Re: [PATCH] Correctly deal with make that has an argument which contains an "s"

[Jason Wessel <jason.wessel@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

On 04/27/2010 06:47 AM, Michal Marek wrote:
> On 26.4.2010 22:56, Jason Wessel wrote:
>> When using remake, which is based on gnumake, if you invoke
>> an example build as shown below, the build will become silent
>> due to the top level make file incorrectly guessing that
>> the end user wants a silent build because an argument that
>> contained an "s" was used.
>>
>> remake --no-extended-errors
> 
> BTW, make --warn-undefined-variables also triggers this (although no one
> will use this option on the kernel makefiles).
> 

Might as well add it to the commit header for clarity. 

>>  
>> -ifneq ($(findstring s,$(MAKEFLAGS)),)
>> +ifneq ($(filter s% -s% --silent --quiet,$(MAKEFLAGS)),)
> 
> I played a bit with GNU make 3.81. Checking for --silent and --quiet is
> not necessary, because make always stores the short option if available.
> Now I was wondering if the 's' option is always at the beginning,
> looking at make-3.81/main.c, it turns out that the order in which the
> options appear in $(MAKEFLAGS) is the reverse order of the switches
> array, where 's' is near the end of the array:
> 
[clip]
> 
> The only other single-letter options that come after 's' (before 's' in
> the $(MAKEFLAGS) variable) are 't', which doesn't work with the kernel,
> and 'w', which doesn't work either (the Makefile adds
> --no-print-directory). So we can indeed get away with s% and -s% (until
> the next make version changes the sort order, that is ;)).
> 

This might be nearly a whole year later, but the problem is still there so perhaps we can reach some closure and get it fixed since it is fairly minor in the first place.  :-)

Version 2 of the original patch is attached.

Thanks,
Jason.

[-- Attachment #2: 0001-Correctly-deal-with-make-that-has-an-argument-which-.patch --]
[-- Type: text/x-diff, Size: 1290 bytes --]

From: Jason Wessel <jason.wessel@windriver.com>
Date: Thu, 5 Jan 2012 16:43:09 -0600
Subject: [PATCH] Correctly deal with make that has an argument which contains
 an "s"

When using remake, which is based on gnumake, if you invoke
an example build as shown below, the build will become silent
due to the top level make file incorrectly guessing that
the end user wants a silent build because an argument that
contained an "s" was used.  Here are two examples one with remake
and one with straight gnumake.

remake --no-extended-errors
make --warn-undefined-variables

Fix up the top level Makefile to use filter to parse the options
that mean silent instead of findstring catching other random
arguments containing an "s".

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
CC: Michal Marek <mmarek@suse.cz>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: linux-kbuild@vger.kernel.org
---
 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index adddd11..4b8ae04 100644
--- a/Makefile
+++ b/Makefile
@@ -312,7 +312,7 @@ endif
 # If the user is running make -s (silent mode), suppress echoing of
 # commands
 
-ifneq ($(findstring s,$(MAKEFLAGS)),)
+ifneq ($(filter s% -s%,$(MAKEFLAGS)),)
   quiet=silent_
 endif
 
-- 
1.7.5.4