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

2017-09-04 Thread Ian Jackson
Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): > On 04.09.17 at 15:33, wrote: > > I would like to make a single change which will always work. After > > all we have no way to automatically verify that we don't have bugs of > > this form, and when we do write a bug of th

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

2017-09-04 Thread Jan Beulich
>>> On 04.09.17 at 15:33, wrote: > I would like to make a single change which will always work. After > all we have no way to automatically verify that we don't have bugs of > this form, and when we do write a bug of this form it's a race bug > (and race bugs are horrible to find and debug). Wel

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

2017-09-04 Thread Ian Jackson
Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): > Well, the absolute paths in there are a problem only when compiling > files from a different subdirectory. Is that something that happens > in many places? It seems to be not wholly uncommon in xen.git, primarily because o

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

2017-09-04 Thread Jan Beulich
>>> On 04.09.17 at 13:33, wrote: > I have investigated this further and have made the following > discoveries: > > 1. make distinguishes targets purely textually. It will canonicalise a > target name by removing ./ before comparison (so `foo' and `./foo' > are considered the same target) but

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

2017-09-04 Thread Ian Jackson
I have investigated this further and have made the following discoveries: 1. make distinguishes targets purely textually. It will canonicalise a target name by removing ./ before comparison (so `foo' and `./foo' are considered the same target) but it won't examine the filesystem AFAICT. So

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

2017-09-04 Thread Ian Jackson
Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): > On 01.09.17 at 19:04, wrote: > > 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 hvmload

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

2017-09-04 Thread Jan Beulich
>>> On 01.09.17 at 19:04, wrote: > Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): >> On 01.09.17 at 17:28, 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 ?

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

2017-09-01 Thread Ian Jackson
Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"): > On 01.09.17 at 17:28, 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 dependenci

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

2017-09-01 Thread Jan Beulich
>>> On 01.09.17 at 17:28, 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 >> --- >> Th

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

2017-09-01 Thread Wei Liu
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 > --- > This wants to be backported to 4.9 and 4.8. >