In particular when cross-compiling or having in place other tool chain
overrides, invoking make to build individual files (e.g. object,
preprocessed, or assembly ones) so far involves putting the various
overrides on the command line instead of simply getting them from
./.config.

Furthermore this helps working around a yet unaddressed make quirk [1]:
Variables put on the command line are invisible to $(shell ...), unless
invoked from a recursive make: During the recursive invocation such
variables are put in the recursive make's environment and hence become
"visible".

Signed-off-by: Jan Beulich <jbeulich@suse.com>

[1] https://savannah.gnu.org/bugs/?10593

--- a/Makefile
+++ b/Makefile
@@ -75,6 +75,13 @@ ifeq (x86_64,$(XEN_TARGET_ARCH))
 	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub-if-enabled
 endif
 
+define do-subtree
+$(1)/%: FORCE
+	$$(MAKE) -C $(1) $$*
+endef
+
+$(foreach m,$(wildcard */Makefile),$(eval $(call do-subtree,$(patsubst %/Makefile,%,$(m)))))
+
 .PHONY: build-docs
 build-docs:
 	$(MAKE) -C docs build
@@ -334,3 +341,6 @@ uninstall: uninstall-tools-public-header
 .PHONY: xenversion
 xenversion:
 	@$(MAKE) --no-print-directory -C xen xenversion
+
+PHONY += FORCE
+FORCE:

On Mon, Mar 28, 2022 at 09:41:26AM +0200, Jan Beulich wrote:
> --- a/Makefile
> +++ b/Makefile
> @@ -75,6 +75,13 @@ ifeq (x86_64,$(XEN_TARGET_ARCH))
>  	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub-if-enabled
>  endif
>  
> +define do-subtree
> +$(1)/%: FORCE
> +	$$(MAKE) -C $(1) $$*
> +endef
> +
> +$(foreach m,$(wildcard */Makefile),$(eval $(call do-subtree,$(patsubst %/Makefile,%,$(m)))))

Any reason to not use $(SUBSYSTEMS) instead of $(wildcard ) ? Or maybe
you would rather been able to run `make xen/foo/bar.o` even after
running `./configure --disable-xen`.

> +
>  .PHONY: build-docs
>  build-docs:
>  	$(MAKE) -C docs build
> @@ -334,3 +341,6 @@ uninstall: uninstall-tools-public-header
>  .PHONY: xenversion
>  xenversion:
>  	@$(MAKE) --no-print-directory -C xen xenversion
> +
> +PHONY += FORCE

That's a Kbuild construct which will not work here. You need to write
".PHONY: FORCE" instead.

In Kbuild, there's a ".PHONY: $(PHONY)", and various macros needs to
know what's .PHONY.


With at least the .PHONY business taking care of: Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks,

-- 
Anthony PERARD

On 29.03.2022 12:28, Anthony PERARD wrote:
> On Mon, Mar 28, 2022 at 09:41:26AM +0200, Jan Beulich wrote:
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -75,6 +75,13 @@ ifeq (x86_64,$(XEN_TARGET_ARCH))
>>  	XEN_TARGET_ARCH=x86_32 $(MAKE) -C stubdom pv-grub-if-enabled
>>  endif
>>  
>> +define do-subtree
>> +$(1)/%: FORCE
>> +	$$(MAKE) -C $(1) $$*
>> +endef
>> +
>> +$(foreach m,$(wildcard */Makefile),$(eval $(call do-subtree,$(patsubst %/Makefile,%,$(m)))))
> 
> Any reason to not use $(SUBSYSTEMS) instead of $(wildcard ) ? Or maybe
> you would rather been able to run `make xen/foo/bar.o` even after
> running `./configure --disable-xen`.

This particular case I don't care about as much, but I think it is
helpful if any subtree which has a Makefile can be recursed into
this way. That way if someone hooks other trees (xtf, mini-os) into
the tree, they're as accessible. As would be subtrees which aren't
subsystems by which still have a Makefile (such may or may not
appear).

>> @@ -334,3 +341,6 @@ uninstall: uninstall-tools-public-header
>>  .PHONY: xenversion
>>  xenversion:
>>  	@$(MAKE) --no-print-directory -C xen xenversion
>> +
>> +PHONY += FORCE
> 
> That's a Kbuild construct which will not work here. You need to write
> ".PHONY: FORCE" instead.
> 
> In Kbuild, there's a ".PHONY: $(PHONY)", and various macros needs to
> know what's .PHONY.

Oh, right - thanks for pointing out. I should have really noticed by
looking at context in the file ...

> With at least the .PHONY business taking care of: Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks.

Jan