[libvirt PATCH 000/351] port libvirt to Meson build system
phrdina at redhat.com
Fri Jul 17 17:00:44 UTC 2020
On Fri, Jul 17, 2020 at 03:24:38PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 16, 2020 at 11:53:56AM +0200, Pavel Hrdina wrote:
> > So I was finally able to produce the patches to port libvirt to Meson.
> > Obviously, it is a lot of changes. It might look that some of the
> > patches could be squashed together but I would rather have it as
> > separated as possible to make the review not that difficult.
> Some things I noticed, building on Fedora 31, with meson 0.55 from pip
> A bunch of warnings from meson:
> WARNING: custom_target 'virtesxgen' has more than one output! Using the first one.
> WARNING: custom_target 'virthypervgen' has more than one output! Using the first one.
> WARNING: custom_target 'protocol.h' has more than one output! Using the first one.
> WARNING: custom_target 'generate-api' has more than one output! Using the first one.
> WARNING: custom_target 'index-api' has more than one output! Using the first one.
> WARNING: custom_target 'index-admin-api' has more than one output! Using the first one.
> WARNING: custom_target 'index-lxc-api' has more than one output! Using the first one.
> WARNING: custom_target 'index-qemu-api' has more than one output! Using the first one.
So it fails with meson 0.55.0 on my Fedora 32 as well. I bisected Meson
repository and this commit <b4b1a2c5a145c1459fc4563a289e164e23bd6a02>
breaks the behavior so I believe it's a bug in Meson.
The warning is generated by any custom_target that has multiple output
files which is obviously incorrect as documentation  states that:
* output: list of output files
I created an issue on github for this warning .
> During build, a bunch of bogus automake style progress messages:
> Generating virtesxgen with a custom command
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_types.generated.typedef
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_types.generated.typeenum
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_types.generated.typetostring
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_types.generated.typefromstring
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_types.generated.h
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_types.generated.c
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_methods.generated.h
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_methods.generated.c
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi_methods.generated.macro
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi.generated.h
> GEN /home/berrange/src/virt/libvirt/build/src/esx/esx_vi.generated.c
> Generating virthypervgen with a custom command
> GEN /home/berrange/src/virt/libvirt/build/src/hyperv/hyperv_wmi_classes.generated.typedef
> GEN /home/berrange/src/virt/libvirt/build/src/hyperv/hyperv_wmi_classes.generated.h
> GEN /home/berrange/src/virt/libvirt/build/src/hyperv/hyperv_wmi_classes.generated.c
These are generated by scripts:
I was ignoring these outputs but I agree that it would be probably nice
to remote it. I'll fix it and push fixed version into gitlab.
> And one problem I think is unrelated / pre-existing, but lost in the noise
> of automake:
> ../tests/qemuxml2xmltest.c: In function ‘mymain’:
> ../tests/qemuxml2xmltest.c:132:1: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without
> 132 | mymain(void)
> | ^~~~~~
It is pre-existing so not addressing it right now as it's unrelated.
> The conversion has introduced 9 new shell scripts in scripts/.
> IMHO, all of these need to be python scripts instead to follow out intent
> to standardize on python. I dream of a world with zero shell scripts.
Sure, works for me. My idea was that these scripts are super simple and
python would be overkill but I'm OK with using python. I'll rewrite it
and push into gitlab.
Thanks for the review.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the libvir-list