On 08.09.14 at 17:23, Ian.Campbell@citrix.com wrote:
ink On Sun, 2014-09-07 at 20:53 -0700, Roy Franz wrote:
--- a/xen/arch/x86/Makefile +++ b/xen/arch/x86/Makefile @@ -75,6 +75,13 @@ $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32 ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o $(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
+# This seems to be required to get parallel builds to work, otherwise prelink-efi.o complains about +# no rule to make boot.init.o
I suppose we must recurse into common and arch at the same time.
+# Not sure what the right fix is
Me neither. This doesn't look right to me though, given that xen/common/efi is also entered via a subdir-y in xen/common/Makefile.
Perhaps Jan has some ideas but I'm wondering if we ought not to recurse into xen/common/efi from here and not from xen/common, or at least to not include extra-$(efi) += boot.init.o in xen/common/efi/Makefile (that would also let the x86 specific checkng code stay here, might it?)
symbols-dummy.o has a similar hack, but notice that it is not build from xen/common/Makefile.
Anyway, I'm flailing, perhaps Jan can suggest the correct fix.
So originally the idea was to sym-link the moved file into its current location, limiting the build recursion to what is being done today.
The only seamless alternative I can see would be to move the whole efi/ subtree to common/ (after all, runtime.c will need to be moved at some point too, and other files should then follow for consistency).
Jan