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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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.

Do people agree ?

Ian.

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