Re: [libvirt PATCH 000/351] port libvirt to Meson build system

On Fri, Jul 17, 2020 at 07:00:44PM +0200, Pavel Hrdina wrote: > 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 [1] states that: > > * output: list of output files > > I created an issue on github for this warning [2]. > > > 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: > > scripts/esx_vi_generator.py > scripts/hyperv_wmi_generator.py > > 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. Even though they are simple, we always have the trapdoor of bash vs non-bash, people always mess up == vs = for example. So using python gives us stronger portability. It would in fact let us build natively on Windows (except for all the other stuff that would break in the actual code if we didn't use mingw :-)