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@xxxxxxxxxx +1-801-349-2682 Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list