Add a new make pattern for creating <file> from <file>.src at build
time. Define the recipe as a macro in order to avoid replicating it
for cases where it needs to handle subdirectories (creating
<dir>/<file> from <dir>/<file>.src).

This can be used instead of the current approach to perform the similar
step for file.in during ./configure by renaming the source file to
file.src.

This will avoid having to run ./configure just because of modifying a
file depending on a variable set by configure.

Prepare to have multiple files as source for the replacement patterns.

Signed-off-by: Juergen Gross <jgross@suse.com>
---
 Config.mk | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Config.mk b/Config.mk
index e1556dfbfa..0ea1640371 100644
--- 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)
+
 CFLAGS += -fno-strict-aliasing
 
 CFLAGS += -std=gnu99
-- 
2.51.0

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.)

Jan

On 13.11.25 17:49, 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)?

With enumerating the files to generate we could probably stick to *.in.

I'm fine with moving the rule to the tools and docs makefiles, but I'd
like to keep the apply-build-vars definition here in order to avoid
duplicating it.

> Also - why the double colon here?

I've followed the advice in the make reference for "match-anything pattern
rules".

With enumerating the files to generate it should be possible to avoid the
double colon.


Juergen

On 14.11.2025 07:18, Jürgen Groß wrote:
> On 13.11.25 17:49, 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)?
> 
> With enumerating the files to generate we could probably stick to *.in.
> 
> I'm fine with moving the rule to the tools and docs makefiles, but I'd
> like to keep the apply-build-vars definition here in order to avoid
> duplicating it.

Oh, sure, I indeed meant only the rule to move.

Jan

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