On 29.06.2020 18:30, Anthony PERARD wrote:
> On Fri, Jun 26, 2020 at 05:02:30PM +0200, Jan Beulich wrote:
>> While I've been running into an issue here only because of an additional
>> local change I'm carrying, to be able to override just the compiler in
>> $(XEN_ROOT)/.config (rather than the whole tool chain), in
>> config/StdGNU.mk:
>>
>> ifeq ($(filter-out default undefined,$(origin CC)),)
>>
>> I'd like to propose to nevertheless correct the underlying issue:
>> Exporting an unset variable changes its origin from "undefined" to
>> "file". This comes into effect because of our adding of -rR to
>> MAKEFLAGS, which make 3.82 wrongly applies also upon re-invoking itself
>> after having updated auto.conf{,.cmd}.
>>
>> Move the export statement past $(XEN_ROOT)/config/$(XEN_OS).mk inclusion
>> such that the variables already have their designated values at that
>> point, while retaining their initial origin up to the point they get
>> defined.
>>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>>
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -17,8 +17,6 @@ export XEN_BUILD_HOST ?= $(shell hostnam
>> PYTHON_INTERPRETER := $(word 1,$(shell which python3 python python2
>> 2>/dev/null) python)
>> export PYTHON ?= $(PYTHON_INTERPRETER)
>>
>> -export CC CXX LD
>> -
>> export BASEDIR := $(CURDIR)
>> export XEN_ROOT := $(BASEDIR)/..
>>
>> @@ -42,6 +40,8 @@ export TARGET_ARCH := $(shell echo $
>> # Allow someone to change their config file
>> export KCONFIG_CONFIG ?= .config
>>
>> +export CC CXX LD
>> +
>> .PHONY: default
>> default: build
>
> That patch is fine and it is probably better to export a variable that
> has a value rather than before the variable is set.
>
> Reviewed-by: Anthony PERARD <anthony.per...@citrix.com>
Paul - thoughts either way as to 4.14? If not to go in now, I
definitely intend to backport it. (And in fact I'm meanwhile
considering to enter a make bug for the behavior, unless its
behavior has changed in later versions.)
Thanks, Jan
