On Fri, Jul 17, 2020 at 06:14:13PM +0100, Daniel P. Berrangé wrote:
> 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 :-)
Make sense, the only one that will be tricky is probably the current
workaround to run python scripts with correct LC_* configuration:
scripts/meson-python.sh
But I'll see once I start converting them into python.
Pavel
Attachment:
signature.asc
Description: PGP signature
