On Mon, Sep 8, 2014 at 8:33 AM, Jan Beulich JBeulich@suse.com wrote:
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.
I think this will be the cleanest - that will allow ARM to use the standard common build stuff, and x86 to do exactly what it did before. I'll do this in the next version.
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