On 13/11/2025 4:49 pm, Jan Beulich wrote:
> On 11.11.2025 17:19, Juergen Gross wrote:
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -159,6 +159,20 @@ 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)
>> +
>> +BUILD_MAKE_VARS := $(foreach f, $(PATH_FILES), $(shell awk '$$2 == ":=" {
>> print $$1; }' $(XEN_ROOT)/config/$(f).mk.in))
>> +
>> +define apply-build-vars
>> + sed $(foreach v, $(BUILD_MAKE_VARS), -e 's#@$(v)@#$($(v))#g') <$< >$@
>> +endef
>> +
>> +%:: %.src
>> + $(apply-build-vars)
> I'm not convinced of having this here, rather than in less central places (say
> under tools/ and docs/). I'm also not sure I really understand why it needs to
> be .src - can't we stick to .in, enumerating the specific files that want
> generating this way (thus avoiding accidental attempts to re-generate files
> which need generating a different way)?
>
> Also - why the double colon here?
>
> (Maybe I figure answers to these questions as I look at subsequent patches.)
I too am wondering about .src vs .in.
.in is a well known naming scheme, and the exact point in the build
where it's generated isn't of interest IMO. I've not come across .src
before, as far as I'm aware.
Is it going to cause a problem to keep all these files named .in ?
~Andrew
