Re: [XEN PATCH v9 03/30] build: fix exported variable name CFLAGS_stack_boundary

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.01.2022 16:04, Anthony PERARD wrote:
> On Fri, Jan 28, 2022 at 12:14:58PM +0100, Jan Beulich wrote:
>> On 25.01.2022 12:00, Anthony PERARD wrote:
>>> Exporting a variable with a dash doesn't work reliably, they may be
>>> striped from the environment when calling a sub-make or sub-shell.
>>>
>>> CFLAGS-stack-boundary start to be removed from env in patch "build:
>>> set ALL_OBJS in main Makefile; move prelink.o to main Makefile" when
>>> running `make "ALL_OBJS=.."` due to the addition of the quote. At
>>> least in my empirical tests.
>>>
>>> Fixes: 2740d96efd ("xen/build: have the root Makefile generates the CFLAGS")
>>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
>>
>> While I did commit this, I'm still somewhat confused. How would quoting
>> of elements on a make command line make a difference to which variables
>> get exported?
> 
> I don't know, maybe without quote, make run sub-make directly, but with
> double-quote, a shell is used.
> 
> But after reading the manual, I didn't expect the variable to be passed
> down sub-make at all:
> 
>     5.7.2 Communicating Variables to a Sub-make
> 
>     Except by explicit request, make exports a variable only if it is
>     either defined in the environment initially or set on the command
>     line, and if its name consists only of letters, numbers, and
>     underscores.
> 
> But somehow, sub-makes also export the non-shell-exportable variables,
> unless the command line in a recipe invoking make has double-quotes.
> 
> 
> I've tried again, and checked the process list:
>   - when running `$(MAKE) -C foo`; make just execute make
>   - when running `$(MAKE) -C 'foo'`; make just execute make
>   - when running `$(MAKE) -C "foo"`; make execute /bin/sh -c ...
>   - when running `$(MAKE) -C foo | tee`; make execute /bin/sh -c ...
> 
> So, CFLAGS-stack-boundary disappear when /bin/sh is involved.

Very "interesting" behavior.

>> In any event I understand the description that prior to the subsequent
>> change there's not actually any issue. Hence I'm not going to queue
>> this for backporting despite the Fixes: tag. Unless of course I'm told
>> otherwise (with justification).
> 
> Justification would be that it's not supposed to work, based on
> information from make's manual.

Okay, I'll queue it then, but in case it doesn't backport
straightforwardly I'll still consider leaving it out.

Jan