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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.09.17 at 17:28, <wei.liu2@xxxxxxxxxx> wrote:
> On Wed, Aug 30, 2017 at 01:06:10AM -0600, Jan Beulich wrote:
>> Short-circuit absolute paths of generated headers to their pathless
>> equivalents, to avoid two racing invocations of the same rule producing
>> them.
>> 
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> This wants to be backported to 4.9 and 4.8.
>> 
>> --- a/tools/libxl/Makefile
>> +++ b/tools/libxl/Makefile
>> @@ -264,6 +264,13 @@ $(LIBXL_OBJS) $(LIBXL_TEST_OBJS) $(LIBXL
>>      $(TEST_PROG_OBJS) $(SAVE_HELPER_OBJS): libxl.h
>>  $(LIBXL_OBJS) $(LIBXL_TEST_OBJS): libxl_internal.h
>>  
>> +# libacpi sources (living in another subdirectory) will have their 
> inclusions
>> +# of headers from this directory recorded as absolute paths in the .*.o.d
>> +# files.  In order to not invoke the subsequent rule twice (and perhaps in 
> a
>> +# racing way when doing a parallel build), short-circuit the absolute paths 
> to
>> +# the local ones first.
>> +$(CURDIR)/_libxl_type%.h: _libxl_type%.h ;
> 
> I don't quite get this. I normally build with -j8 and never saw a race.

I rarely do incremental tools builds, but each time I do them
(on 4.8 or later) I run into this issue.

> Do you mean parallel build in which two makes enter libxl? Is that
> possible?

No, only a single entry into that subtree.

> Why does libacpi matter? All dependencies files (*.o.d) should be local
> to libxl anyway.

Did you check? My .build.o.d has:

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

Jan


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