[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v9 03/30] build: fix exported variable name CFLAGS_stack_boundary
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |