Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"):
> On 01.09.17 at 17:28, <wei.liu2@xxxxxxxxxx> wrote:
> > Do you mean parallel build in which two makes enter libxl? Is that
> > possible?
> 
> No, only a single entry into that subtree.

Are you sure ?

> > Why does libacpi matter? All dependencies files (*.o.d) should be local
> > to libxl anyway.
> 
> Did you check? My .build.o.d has:

AFAICT you must mean tools/firmware/hvmloader/.build.o.d ?

> build.o:  \
>  /build/xen/unstable-hg/2017-08-10/tools/libxl/../../tools/libacpi/build.c \
>   /build/xen/unstable-hg/2017-08-10/tools/libxl/../../tools/config.h \
>   /build/xen/unstable-hg/2017-08-10/tools/libxl/libxl_x86_acpi.h \
> [...]
>   _libxl_list.h \
>   /build/xen/unstable-hg/2017-08-10/tools/libxl/_libxl_types.h \
>   libxl_event.h libxl.h \
> [...]
> 
> and it is this non-local _libxl_types.h dependency which breaks
> things. I've noted this with gcc 4.3.x, in case that matters (e.g.
> if newer compilers are smarter in how they write out deps).

This suggests that perhaps the problem is that something is reentering
libxl.

With recursive make, it is necessary for the overall structure of the
makefiles to sequence things so that each directory is entered exactly
once, before its dependent directories are entered.  (It is possible
to violate this rule without creating races but it is tricky and
inadvisable.)

Can you provide a complete log of a failing build ?

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel