On 11.12.2025 15:26, Jan Beulich wrote:
> On 21.11.2025 14:23, Juergen Gross wrote:
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -159,6 +159,19 @@ define move-if-changed
>> if ! cmp -s $(1) $(2); then mv -f $(1) $(2); else rm -f $(1); fi
>> endef
>>
>> +PATH_FILES := Paths
>> +INC_FILES = $(foreach f, $(PATH_FILES), $(XEN_ROOT)/config/$(f).mk)
>> +
>> +include $(INC_FILES)
>
> And now a failing build tells me why by a gut feeling I didn't like this.
> Being placed here, it affects the hypervisor build as well. The hypervisor
> build, in its _install rule, uses $(DEBUG_DIR), first in
>
> [ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR)
>
> $(D) is an absolute directory (shorthand for $(DESTDIR)). $(DEBUG_DIR) as
> set by Paths.mk is, too. Both point into the build tree. The two simply
> shouldn't be glued together.
>
> Note that the earlier
>
> [ -d $(D)$(BOOT_DIR) ] || $(INSTALL_DIR) $(D)$(BOOT_DIR)
>
> continues to be working fine, as BOOT_DIR continues to be controlled by
> config/StdGNU.mk. Its DEBUG_DIR isn't taking effect anymore, when for the
> hypervisor build it should.
>
> And of course behavior now differs between building xen/ in a tree where
> tools/ was built before vs in an otherwise clean tree.
Below is what I'm testing as a workaround, but I'm neither sure it's
reasonable to do something like this upstream, nor am I fully convinced of
its correctness just yet. The shim build looks to be working fine, which
is where I was concerned the most.
Jan
--- a/Config.mk
+++ b/Config.mk
@@ -191,7 +191,9 @@ endef
PATH_FILES := Paths.mk
INC_FILES = $(foreach f, $(PATH_FILES), $(XEN_ROOT)/config/$(f))
+ifndef XEN_FULLVERSION
-include $(INC_FILES)
+endif
BUILD_MAKE_VARS = $(foreach f, $(PATH_FILES), $(shell awk '$$2 == ":=" { print
$$1; }' $(XEN_ROOT)/config/$(f).in))
