On 08/24/2010 07:21 AM, Daniel P. Berrange wrote:
Very occasionally during a parallel make, dispatch.c would
be compiled before the generated remote headers had been
fully written. This would cause it to compile an empty
union, and result in really wierd runtime bugs that are
s/wierd/weird/
near impossible to diagnose.
* daemon/Makefile.am: Fix remote build deps
---
daemon/Makefile.am | 19 +++++++++++--------
1 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index dbf0ac3..035c149 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -189,14 +189,17 @@ uninstall-data-polkit::
endif
-remote.c: remote_dispatch_prototypes.h \
- remote_dispatch_table.h \
- remote_dispatch_args.h \
- remote_dispatch_ret.h \
- qemu_dispatch_prototypes.h \
- qemu_dispatch_table.h \
- qemu_dispatch_args.h \
- qemu_dispatch_ret.h
+remote.c: \
+ remote_dispatch_prototypes.h \
+ remote_dispatch_table.h \
+ qemu_dispatch_prototypes.h \
+ qemu_dispatch_table.h
+
+remote.h: \
+ remote_dispatch_args.h \
+ remote_dispatch_ret.h \
+ qemu_dispatch_args.h \
+ qemu_dispatch_ret.h
I agree that the explicit remote.h dependencies are needed, since
remote.h is in turn included by dispatch.c.
I wonder if you're still missing something. Since both dispatch.c and
remote.c do #include's remote.h, shouldn't they both also list remote.h
(or remote.h's generated headers) as dependencies? On the other hand,
maybe you already get this for free from automake (which uses gcc's -M
options to pick up automatic dependency tracking based on #include
contents) - I do see remote.h listed in both
daemon/.deps/libvirtd-{remote,dispatch}.Po.
On the other hand, where is the action that updates the timestamp of
remote.[ch] to be newer than their generated .h counterparts? Without
that rule, then every run of make will see the generated files with a
newer timestamp than the version-controlled files, and insist on
regenerating the headers; whereas if you touched remote.[ch] after all
the generated headers are up-to-date, then successive make runs will see
that there is nothing left to do.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org