Re: [PATCH] libxl: fix incremental parallel build

From: "Jan Beulich" <JBeulich@suse.com>
To: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH] libxl: fix incremental parallel build
Date: Mon, 04 Sep 2017 02:38:34 -0600	[thread overview]
Message-ID: <59AD2D2A0200007800176FE0@prv-mh.provo.novell.com> (raw)
In-Reply-To: <22953.37663.137446.496414@mariner.uk.xensource.com>

>>> On 01.09.17 at 19:04, <ian.jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"):
>> On 01.09.17 at 17:28, <wei.liu2@citrix.com> 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 ?

Yes.

>> > 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 ?

No, I mean the libxl instance of the file (remember that the same
libacpi source file is being compiled twice). The hvmloader instance
looks similar, but doesn't cause the same problem (because there
are no auto-generated headers).

>> 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.

Again, I've verified (multiple times) that this is not the case, as I
too did initially suspect this to be what is happening.

> 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.)

I understand that.

> Can you provide a complete log of a failing build ?

With the above, is that really needed? And if so, do you mean
just normal make output, or output from additionally passing -p.

Jan

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