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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.09.17 at 13:33, <ian.jackson@xxxxxxxxxxxxx> 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 it won't examine the filesystem
>   AFAICT.  So `foo' and `../../this/subdir/foo' are different targets.
>   (You seem to have already observed or known this.)
> 
> 2. If you use gcc -MMD to generate a .d file, and say -I. to include
>   things from the cwd, but invoke gcc to compile a file elsewhere, eg
>      gcc -MMD -I -o build.o /other/path/build.c
>   and build.c #includes `foo.h', then the -MMD output mentions
>   `/absolute/path/to/this/subdir/foo.h', even though it could refer
>   to `foo.h'.  (VPATH and vpath are obvious ways for this to happen.)
>   This is presumably because gcc has noticed that `.' in this context
>   must mean relative to the invocation cwd, not relative to build.c.
> 
> 3. If foo.h is autogenerated using some kind of pattern rule,
>   you end up with two `copies' of the rule, which can run
>   simultaneously, once for build.c -> build.o and once for normal
>   files in the same cwd.
> 
> I think (2) is a bug in gcc.  But we can't sensibly expect to fix
> that.  Sadly I think the right fix is to seddery the pointless paths
> out of the .d files.
> 
> I don't think going round all our Makefiles adding rules of the form
>    $(ABS_PATH_TO_HERE)/auto-%-generated.: auto-%-generated.h
> is sensible.  There are too many and this is too ad-hoc.

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? I would agree to the sed approach you suggest if
this was a widespread problem, but I don't think it is (and hence I
went this other route).

Jan


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