Re: [XEN PATCH v9 04/30] build: set ALL_OBJS in main Makefile; move prelink.o to main Makefile

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.01.2022 12:00, Anthony PERARD wrote:
> This is to avoid arch/$arch/Makefile having to recurse into parents
> directories.
> 
> This avoid duplication of the logic to build prelink.o between arches.
> 
> In order to do that, we cut the $(TARGET) target in the main Makefile in
> two, there is a "prepare" phase/target runned before starting to build
> "prelink.o" which will prepare "include/" among other things, then all
> the $(ALL_OBJS) will be generated in order to build "prelink.o" and
> finally $(TARGET) will be generated by calling into "arch/*/" to make
> $(TARGET).
> 
> Now we don't need to prefix $(ALL_OBJS) with $(BASEDIR) as it is now
> only used from the main Makefile. Other changes is to use "$<" instead
> of spelling "prelink.o" in the target "$(TARGET)" in both
> arch/*/Makefile.
> 
> Beside "prelink.o" been at a different location, no other functional
> change intended.
> 
> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
with a remark and maybe a small adjustment suggestion:

> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -285,6 +285,16 @@ CFLAGS += -flto
>  LDFLAGS-$(CONFIG_CC_IS_CLANG) += -plugin LLVMgold.so
>  endif
>  
> +# Note that link order matters!

Merely as a remark: I wonder how applicable that comment is anymore.
If anything I'd expect it to be relevant to $(TARGET_SUBARCH)/head.o
(Arm) and boot/built_in.o (x86), neither of which get named here.

> @@ -407,7 +417,7 @@ $(TARGET): FORCE
>       $(MAKE) -f $(BASEDIR)/Rules.mk -C include
>       $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) include
>       $(MAKE) -f $(BASEDIR)/Rules.mk 
> arch/$(TARGET_ARCH)/include/asm/asm-offsets.h
> -     $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) 
> MKRELOC=$(MKRELOC) $@
> +     $(MAKE) -f $(BASEDIR)/Rules.mk MKRELOC=$(MKRELOC) 
> "ALL_OBJS=$(ALL_OBJS-y)" "ALL_LIBS=$(ALL_LIBS-y)" $@

I'm always a little wary of using double quotes when it's not clear
what exactly a macro may expand to. Single quotes at least have less
restrictions ...

Jan