Re: [Xen-devel] [PATCH] Kconfig: fix environment variable handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.01.16 at 16:44, <ian.campbell@xxxxxxxxxx> wrote:
> On Wed, 2016-01-13 at 03:46 -0700, Jan Beulich wrote:
>> With xen/Makefile including include/config/auto.conf.cmd, environment
>> variables checked in the latter must be available at the time of
>> inclusion of that file, and hence must be populated in xen/Makefile
>> rather than by passing to or inside xen/tools/kconfig/Makefile.kconfig.
>> Otherwise incremental re-builds will always be full re-builds, which is
>> not only annoying but actively problematic when building as non-root
>> and only running "install-xen" as root.
>> 
>> Also take the opportunity and remove stray $(Q) uses.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> 
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -20,6 +20,9 @@ MAKEFLAGS += -rR
>>  
>>  EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi
>>  
>> +ARCH=$(XEN_TARGET_ARCH)
>> +SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e 
>> s'/arm\(32\|64\)/arm/g')
> 
> Why not just use XEN_TARGET_ARCH and TARGET_ARCH as defined in
> xen/Rules.mk, at the point where recursing into kconfig/Makefile.kconfig?

xen/Makefile doesn't include xen/Rules.mk afaics. And the recursion
into kconfig/Makefile.kconfig doesn't use it either (and probably
shouldn't, as we want to keep the two environments distinct, in
order to not risk collisions).

> Otherwise wouldn't we risk SRCARCH and TARGET_ARCH getting out of sync?

That would be bad indeed, but no worse than before this patch
(which just moves it). I vaguely recall even maybe having
commented on that duplication in the context of the Kconfig series.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel