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.per...@citrix.com>
>>
>> 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
