[PATCH] add build dependency on lxc_protocol.h to remote_daemon
remote_daemon.c and others need the generated header lxc_protocol.h, but do not have it as a dependency in meson.build. This means that builds will randomly (ok, very occasionally) fail. Restructure how the header is built so that remote_daemon can have it as a dependency. Signed-off-by: Joe Slater <joe.slater@windriver.com> --- src/remote/meson.build | 48 ++++++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 20 deletions(-) diff --git a/src/remote/meson.build b/src/remote/meson.build index 0a18826..31a30ee 100644 --- a/src/remote/meson.build +++ b/src/remote/meson.build @@ -1,27 +1,11 @@ -remote_driver_sources = [ - 'remote_driver.c', - 'remote_sockets.c', -] - -remote_driver_generated = [] +remote_xxx_generated = [] foreach name : [ 'remote', 'qemu', 'lxc' ] - client_bodies_h = '@0@_client_bodies.h'.format(name) protocol_c = '@0@_protocol.c'.format(name) protocol_h = '@0@_protocol.h'.format(name) protocol_x = '@0@_protocol.x'.format(name) - remote_driver_generated += custom_target( - client_bodies_h, - input: protocol_x, - output: client_bodies_h, - command: [ - gendispatch_prog, '--mode=client', name, name.to_upper(), '@INPUT@', - ], - capture: true, - ) - - remote_driver_generated += custom_target( + remote_xxx_generated += custom_target( protocol_h, input: protocol_x, output: protocol_h, @@ -30,7 +14,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] ], ) - remote_driver_generated += custom_target( + remote_xxx_generated += custom_target( protocol_c, input: protocol_x, output: protocol_c, @@ -42,6 +26,30 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] rpc_probe_files += files(protocol_x) endforeach + +remote_driver_sources = [ + 'remote_driver.c', + 'remote_sockets.c', +] + +remote_driver_generated =remote_xxx_generated + +foreach name : [ 'remote', 'qemu', 'lxc' ] + client_bodies_h = '@0@_client_bodies.h'.format(name) + protocol_x = '@0@_protocol.x'.format(name) + + remote_driver_generated += custom_target( + client_bodies_h, + input: protocol_x, + output: client_bodies_h, + command: [ + gendispatch_prog, '--mode=client', name, name.to_upper(), '@INPUT@', + ], + capture: true, + ) + +endforeach + remote_daemon_sources = files( 'remote_daemon.c', 'remote_daemon_config.c', @@ -49,7 +57,7 @@ remote_daemon_sources = files( 'remote_daemon_stream.c', ) -remote_daemon_generated = [] +remote_daemon_generated = remote_xxx_generated virt_ssh_helper_sources = files( 'remote_sockets.c', -- 2.32.0
On 3/10/22 21:53, Joe Slater wrote:
remote_daemon.c and others need the generated header lxc_protocol.h, but do not have it as a dependency in meson.build. This means that builds will randomly (ok, very occasionally) fail. Restructure how the header is built so that remote_daemon can have it as a dependency.
Signed-off-by: Joe Slater <joe.slater@windriver.com>
--- src/remote/meson.build | 48 ++++++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/src/remote/meson.build b/src/remote/meson.build index 0a18826..31a30ee 100644 --- a/src/remote/meson.build +++ b/src/remote/meson.build @@ -1,27 +1,11 @@ -remote_driver_sources = [ - 'remote_driver.c', - 'remote_sockets.c', -] - -remote_driver_generated = [] +remote_xxx_generated = []
foreach name : [ 'remote', 'qemu', 'lxc' ] - client_bodies_h = '@0@_client_bodies.h'.format(name) protocol_c = '@0@_protocol.c'.format(name) protocol_h = '@0@_protocol.h'.format(name) protocol_x = '@0@_protocol.x'.format(name)
- remote_driver_generated += custom_target( - client_bodies_h, - input: protocol_x, - output: client_bodies_h, - command: [ - gendispatch_prog, '--mode=client', name, name.to_upper(), '@INPUT@', - ], - capture: true, - ) - - remote_driver_generated += custom_target( + remote_xxx_generated += custom_target( protocol_h, input: protocol_x, output: protocol_h, @@ -30,7 +14,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] ], )
- remote_driver_generated += custom_target( + remote_xxx_generated += custom_target( protocol_c, input: protocol_x, output: protocol_c, @@ -42,6 +26,30 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] rpc_probe_files += files(protocol_x) endforeach
+ +remote_driver_sources = [ + 'remote_driver.c', + 'remote_sockets.c', +] + +remote_driver_generated =remote_xxx_generated + +foreach name : [ 'remote', 'qemu', 'lxc' ] + client_bodies_h = '@0@_client_bodies.h'.format(name) + protocol_x = '@0@_protocol.x'.format(name) + + remote_driver_generated += custom_target( + client_bodies_h, + input: protocol_x, + output: client_bodies_h, + command: [ + gendispatch_prog, '--mode=client', name, name.to_upper(), '@INPUT@', + ], + capture: true, + ) + +endforeach + remote_daemon_sources = files( 'remote_daemon.c', 'remote_daemon_config.c', @@ -49,7 +57,7 @@ remote_daemon_sources = files( 'remote_daemon_stream.c', )
-remote_daemon_generated = [] +remote_daemon_generated = remote_xxx_generated
So IIUC, this fix consists of two parts: 1) generating client_bodies_h only AFTER protocol.x for all three drivers was processed, 2) Initializing remote_daemon_generated to remote_xxx_generated (which contains protocol.x processing targets). IMO, it's only the second step that's really needed, isn't it? I'm not against this patch, I'm just trying to confirm I understood the problem and the fix. Michal
I was really only wanting to make sure that both remote_driver and remote_daemon have access to lxc_protocol.h. I am not an expert in meson builds but I think the only way to do that is have a loop outside of remote_daemon_generated and remote_driver_generated. You could start with an empty remote_daemon_generated and append remote_xxx_generated after the foreach loop instead of initializing the way I did. So, your 1) is just a side-effect, not something I was explicitly seeking. Joe
-----Original Message----- From: Michal Prívozník <mprivozn@redhat.com> Sent: Monday, March 14, 2022 3:13 AM To: Slater, Joseph <joe.slater@windriver.com>; libvir-list@redhat.com Cc: MacLeod, Randy <Randy.MacLeod@windriver.com> Subject: Re: [PATCH] add build dependency on lxc_protocol.h to remote_daemon
On 3/10/22 21:53, Joe Slater wrote:
remote_daemon.c and others need the generated header lxc_protocol.h, but do not have it as a dependency in meson.build. This means that builds will randomly (ok, very occasionally) fail. Restructure how the header is built so that remote_daemon can have it as a dependency.
Signed-off-by: Joe Slater <joe.slater@windriver.com>
--- src/remote/meson.build | 48 ++++++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/src/remote/meson.build b/src/remote/meson.build index 0a18826..31a30ee 100644 --- a/src/remote/meson.build +++ b/src/remote/meson.build @@ -1,27 +1,11 @@ -remote_driver_sources = [ - 'remote_driver.c', - 'remote_sockets.c', -] - -remote_driver_generated = [] +remote_xxx_generated = []
foreach name : [ 'remote', 'qemu', 'lxc' ] - client_bodies_h = '@0@_client_bodies.h'.format(name) protocol_c = '@0@_protocol.c'.format(name) protocol_h = '@0@_protocol.h'.format(name) protocol_x = '@0@_protocol.x'.format(name)
- remote_driver_generated += custom_target( - client_bodies_h, - input: protocol_x, - output: client_bodies_h, - command: [ - gendispatch_prog, '--mode=client', name, name.to_upper(), '@INPUT@', - ], - capture: true, - ) - - remote_driver_generated += custom_target( + remote_xxx_generated += custom_target( protocol_h, input: protocol_x, output: protocol_h, @@ -30,7 +14,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] ], )
- remote_driver_generated += custom_target( + remote_xxx_generated += custom_target( protocol_c, input: protocol_x, output: protocol_c, @@ -42,6 +26,30 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] rpc_probe_files += files(protocol_x) endforeach
+ +remote_driver_sources = [ + 'remote_driver.c', + 'remote_sockets.c', +] + +remote_driver_generated =remote_xxx_generated + +foreach name : [ 'remote', 'qemu', 'lxc' ] + client_bodies_h = '@0@_client_bodies.h'.format(name) + protocol_x = '@0@_protocol.x'.format(name) + + remote_driver_generated += custom_target( + client_bodies_h, + input: protocol_x, + output: client_bodies_h, + command: [ + gendispatch_prog, '--mode=client', name, name.to_upper(), '@INPUT@', + ], + capture: true, + ) + +endforeach + remote_daemon_sources = files( 'remote_daemon.c', 'remote_daemon_config.c', @@ -49,7 +57,7 @@ remote_daemon_sources = files( 'remote_daemon_stream.c', )
-remote_daemon_generated = [] +remote_daemon_generated = remote_xxx_generated
So IIUC, this fix consists of two parts: 1) generating client_bodies_h only AFTER protocol.x for all three drivers was processed, 2) Initializing remote_daemon_generated to remote_xxx_generated (which contains protocol.x processing targets).
IMO, it's only the second step that's really needed, isn't it? I'm not against this patch, I'm just trying to confirm I understood the problem and the fix.
Michal
On 3/14/22 15:58, Slater, Joseph wrote:
I was really only wanting to make sure that both remote_driver and remote_daemon have access to lxc_protocol.h. I am not an expert in meson builds but I think the only way to do that is have a loop outside of remote_daemon_generated and remote_driver_generated. You could start with an empty remote_daemon_generated and append remote_xxx_generated after the foreach loop instead of initializing the way I did.
So, your 1) is just a side-effect, not something I was explicitly seeking.
Hey, I'm no meson expert either, but one thing that I've noticed is that with this patch I'm seeing more tasks that meson wants to run: Without the patch: 1410 With the patch: 1447 (note, that your numbers may be different as they depend on what features are enabled, but you should see the same increase in tasks) My understanding was that we need only to order tasks not add new ones. Now, looking at generated build.ninja I can see why: libvirt.git $ grep "^build.*lxc_protocol.c.o:" build/build.ninja | cut -d':' -f1 build src/remote/libvirt_remote_driver.a.p/meson-generated_.._lxc_protocol.c.o build src/libvirtd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtproxyd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtinterfaced.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnetworkd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnodedevd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnwfilterd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtsecretd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtstoraged.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtxend.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtlxcd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtchd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtqemud.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtvboxd.p/meson-generated_.._remote_lxc_protocol.c.o Meson decided it's faster to compile remote_lxc_protocol.c multiple times, for different daemons, each time with the same set of arguments (not shown in my paste above), than to compile it just once. I'm sure virqemud is going to be happy with understanding LXC driver protocol, but I am not happy about that. Le sigh. Pavel, since you introduced meson, can you please shed more light into here? How should we set up ORDERING and not DEPENDENCY? In Makefile it's as easy as: target: dependency | x y z Michal
On Wed, Mar 16, 2022 at 09:39:52AM +0100, Michal Prívozník wrote:
On 3/14/22 15:58, Slater, Joseph wrote:
I was really only wanting to make sure that both remote_driver and remote_daemon have access to lxc_protocol.h. I am not an expert in meson builds but I think the only way to do that is have a loop outside of remote_daemon_generated and remote_driver_generated. You could start with an empty remote_daemon_generated and append remote_xxx_generated after the foreach loop instead of initializing the way I did.
So, your 1) is just a side-effect, not something I was explicitly seeking.
Hey, I'm no meson expert either, but one thing that I've noticed is that with this patch I'm seeing more tasks that meson wants to run:
Without the patch: 1410 With the patch: 1447
While likely correct in this case, be wary of believing what Meson prints as the total number of tasks it intends to run upfront. I've seen cases where it claimed it needed to run 100's of tasks, then after running 3 tasks, it changed it mind and decided it only needed 15 tasks :-)
My understanding was that we need only to order tasks not add new ones. Now, looking at generated build.ninja I can see why:
libvirt.git $ grep "^build.*lxc_protocol.c.o:" build/build.ninja | cut -d':' -f1 build src/remote/libvirt_remote_driver.a.p/meson-generated_.._lxc_protocol.c.o build src/libvirtd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtproxyd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtinterfaced.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnetworkd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnodedevd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnwfilterd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtsecretd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtstoraged.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtxend.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtlxcd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtchd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtqemud.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtvboxd.p/meson-generated_.._remote_lxc_protocol.c.o
Meson decided it's faster to compile remote_lxc_protocol.c multiple times, for different daemons, each time with the same set of arguments (not shown in my paste above), than to compile it just once. I'm sure virqemud is going to be happy with understanding LXC driver protocol, but I am not happy about that. Le sigh.
I wouldn't say it has decided it is faster to compile many times. In the past meson wasn't compiling it at all for the daemons. AFAICT, currently the daemons only get access to a the remote_protocol.c.o implementations indirectly through linking to libvirt.so With this patch, we are explicitly telling meson to link the daemons with remote_protocol.c.o. Meson strives for maximum correctness, so if an object file is used from many output targets, it will compile the source file separately for each target, to take into account differences in compiler flags used for each output target. IOW, meson is doing exactly what we told it to do here. The result is that the daemons actually get 2 copies of the the remote_protocol.c.o - one copy is directly linked into the binary, and one copy is indirectly via libvirt.so
Pavel, since you introduced meson, can you please shed more light into here? How should we set up ORDERING and not DEPENDENCY? In Makefile it's as easy as:
ORDERING / DEPENDENCY are the same thing. This patch is not actually setting up a dependancy - it is explicitly telling meson to compile the files many times. I suspect what we need is this: diff --git a/src/remote/meson.build b/src/remote/meson.build index b2aafe6320..769fc2e97f 100644 --- a/src/remote/meson.build +++ b/src/remote/meson.build @@ -3,7 +3,8 @@ remote_driver_sources = [ 'remote_sockets.c', ] -remote_driver_generated = [] +remote_generated_sources = [] +remote_generated_headers = [] foreach name : [ 'remote', 'qemu', 'lxc' ] client_bodies_h = '@0@_client_bodies.h'.format(name) @@ -11,7 +12,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] protocol_h = '@0@_protocol.h'.format(name) protocol_x = '@0@_protocol.x'.format(name) - remote_driver_generated += custom_target( + remote_generated_headers += custom_target( client_bodies_h, input: protocol_x, output: client_bodies_h, @@ -21,7 +22,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] capture: true, ) - remote_driver_generated += custom_target( + remote_generated_sources += custom_target( protocol_h, input: protocol_x, output: protocol_h, @@ -30,7 +31,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] ], ) - remote_driver_generated += custom_target( + remote_generated_sources += custom_target( protocol_c, input: protocol_x, output: protocol_c, @@ -49,7 +50,9 @@ remote_daemon_sources = files( 'remote_daemon_stream.c', ) -remote_daemon_generated = [] +remote_driver_generated = remote_generated_headers + remote_generated_sources +# Daemon gets the impls indirectly via libvirt.so +remote_daemon_generated = remote_generated_headers virt_ssh_helper_sources = files( 'remote_sockets.c', (not tested) With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, Mar 16, 2022 at 09:51:48AM +0000, Daniel P. Berrangé wrote:
On Wed, Mar 16, 2022 at 09:39:52AM +0100, Michal Prívozník wrote:
On 3/14/22 15:58, Slater, Joseph wrote:
I was really only wanting to make sure that both remote_driver and remote_daemon have access to lxc_protocol.h. I am not an expert in meson builds but I think the only way to do that is have a loop outside of remote_daemon_generated and remote_driver_generated. You could start with an empty remote_daemon_generated and append remote_xxx_generated after the foreach loop instead of initializing the way I did.
So, your 1) is just a side-effect, not something I was explicitly seeking.
Hey, I'm no meson expert either, but one thing that I've noticed is that with this patch I'm seeing more tasks that meson wants to run:
Without the patch: 1410 With the patch: 1447
While likely correct in this case, be wary of believing what Meson prints as the total number of tasks it intends to run upfront. I've seen cases where it claimed it needed to run 100's of tasks, then after running 3 tasks, it changed it mind and decided it only needed 15 tasks :-)
I've seen that many times. My guess is that it computes the dependency tree and once meson starts compiling things it will notice that some of the bits are already compiled and up to date so there is no need to do it.
My understanding was that we need only to order tasks not add new ones. Now, looking at generated build.ninja I can see why:
libvirt.git $ grep "^build.*lxc_protocol.c.o:" build/build.ninja | cut -d':' -f1 build src/remote/libvirt_remote_driver.a.p/meson-generated_.._lxc_protocol.c.o build src/libvirtd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtproxyd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtinterfaced.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnetworkd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnodedevd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtnwfilterd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtsecretd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtstoraged.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtxend.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtlxcd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtchd.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtqemud.p/meson-generated_.._remote_lxc_protocol.c.o build src/virtvboxd.p/meson-generated_.._remote_lxc_protocol.c.o
Meson decided it's faster to compile remote_lxc_protocol.c multiple times, for different daemons, each time with the same set of arguments (not shown in my paste above), than to compile it just once. I'm sure virqemud is going to be happy with understanding LXC driver protocol, but I am not happy about that. Le sigh.
I wouldn't say it has decided it is faster to compile many times.
In the past meson wasn't compiling it at all for the daemons.
AFAICT, currently the daemons only get access to a the remote_protocol.c.o implementations indirectly through linking to libvirt.so
With this patch, we are explicitly telling meson to link the daemons with remote_protocol.c.o.
Meson strives for maximum correctness, so if an object file is used from many output targets, it will compile the source file separately for each target, to take into account differences in compiler flags used for each output target.
IOW, meson is doing exactly what we told it to do here.
The result is that the daemons actually get 2 copies of the the remote_protocol.c.o - one copy is directly linked into the binary, and one copy is indirectly via libvirt.so
Pavel, since you introduced meson, can you please shed more light into here? How should we set up ORDERING and not DEPENDENCY? In Makefile it's as easy as:
ORDERING / DEPENDENCY are the same thing. This patch is not actually setting up a dependancy - it is explicitly telling meson to compile the files many times.
I suspect what we need is this:
diff --git a/src/remote/meson.build b/src/remote/meson.build index b2aafe6320..769fc2e97f 100644 --- a/src/remote/meson.build +++ b/src/remote/meson.build @@ -3,7 +3,8 @@ remote_driver_sources = [ 'remote_sockets.c', ]
-remote_driver_generated = [] +remote_generated_sources = [] +remote_generated_headers = []
foreach name : [ 'remote', 'qemu', 'lxc' ] client_bodies_h = '@0@_client_bodies.h'.format(name) @@ -11,7 +12,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] protocol_h = '@0@_protocol.h'.format(name) protocol_x = '@0@_protocol.x'.format(name)
- remote_driver_generated += custom_target( + remote_generated_headers += custom_target( client_bodies_h, input: protocol_x, output: client_bodies_h, @@ -21,7 +22,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] capture: true, )
- remote_driver_generated += custom_target( + remote_generated_sources += custom_target(
this should be `remote_generated_headers += custom_target(`
protocol_h, input: protocol_x, output: protocol_h, @@ -30,7 +31,7 @@ foreach name : [ 'remote', 'qemu', 'lxc' ] ], )
- remote_driver_generated += custom_target( + remote_generated_sources += custom_target( protocol_c, input: protocol_x, output: protocol_c, @@ -49,7 +50,9 @@ remote_daemon_sources = files( 'remote_daemon_stream.c', )
-remote_daemon_generated = [] +remote_driver_generated = remote_generated_headers + remote_generated_sources +# Daemon gets the impls indirectly via libvirt.so +remote_daemon_generated = remote_generated_headers
virt_ssh_helper_sources = files( 'remote_sockets.c',
(not tested)
otherwise looks good and should fix the issue. Pavel
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (5)
-
Daniel P. Berrangé -
Joe Slater -
Michal Prívozník -
Pavel Hrdina -
Slater, Joseph