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 :|
>