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

Pavel Hrdina phrdina at redhat.com
Fri Jul 17 15:49:42 UTC 2020


On Fri, Jul 17, 2020 at 04:53:28PM +0200, Peter Krempa wrote:
> On Fri, Jul 17, 2020 at 16:37:45 +0200, Peter Krempa wrote:
> > On Fri, Jul 17, 2020 at 16:31:05 +0200, Peter Krempa wrote:
> > > On Fri, Jul 17, 2020 at 16:18:52 +0200, Peter Krempa wrote:
> > > > On Fri, Jul 17, 2020 at 16:04:16 +0200, Peter Krempa wrote:
> > > > > On Thu, Jul 16, 2020 at 11:53:56 +0200, Pavel Hrdina wrote:
> > > > > 
> > > > > I've tried building RPMs both from the pre-patch tree state and after
> > > > > your patchset. I've then extracted all the RPMs toghether and compared
> > > > > the file lists (minus the 'build-id' directory which differs).
> > > > > 
> > > > > I'm not sure whether it's due to the RPM or regular build process
> > > > > though.
> > > > 
> > > 
> > > Another difference is paths to shared objects:
> > > 
> > > e.g virsh:
> > > 
> > > automakerpm/unpack/usr/bin/virsh:
> > > 	linux-vdso.so.1 (0x00007ffccb1ea000)
> > > 	libvirt-lxc.so.0 => /lib64/libvirt-lxc.so.0 (0x00007f51f7082000)
> > > 	libvirt-qemu.so.0 => /lib64/libvirt-qemu.so.0 (0x00007f51f707d000)
> > > 	libvirt.so.0 => /lib64/libvirt.so.0 (0x00007f51f6bbd000)
> > > 	libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f51f6a4d000)
> > > 	libreadline.so.8 => /lib64/libreadline.so.8 (0x00007f51f69f7000)
> > > 	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f51f68cc000)
> > > 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f51f68a8000)
> > > 
> > > mesonrpm/unpack/usr/bin/virsh:
> > > 	linux-vdso.so.1 (0x00007ffcb4b8d000)
> > > 	libvirt-lxc.so.0 => /usr/lib64/libvirt-lxc.so.0 (0x00007fc2b9596000)
> > > 	libvirt-qemu.so.0 => /usr/lib64/libvirt-qemu.so.0 (0x00007fc2b9591000)
> > > 	libvirt.so.0 => /usr/lib64/libvirt.so.0 (0x00007fc2b90d1000)
> > > 	libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00007fc2b8f61000)
> > > 	libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007fc2b8e36000)
> > > 	libreadline.so.8 => /usr/lib64/libreadline.so.8 (0x00007fc2b8de0000)
> > > 	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fc2b8dc3000)
> > > 
> > > 
> > > This one is probably safe and also possibly considered modern, but I
> > > wanted to point it out.
> > > 
> > > One mistake though is that usr/bin/virt-xml-validate is not installed as
> > > executalbe with meson!
> > 
> > Also virt-pki-validate
> > 
> 
> And virt-sanlock-cleanup in usr/sbin/

Already fixed, thanks.

> usr/share/doc/libvirt-docs/README is a symlink with meson ... the
> automake version
> doesn't differ. Is it even worth having them?

The symlink is also in our repository, I was not able to find any rule
in autoconf that would do anything with it. The difference exists in
the tarballs so it's some autotools magic that I'm not willing to
investigate.

> then
> 
> usr/share/doc/libvirt-docs/AUTHORS '#contributorslist#' is not expanded
> with meson

Fixed, thanks, it has to be '@contributorslist@' to expand it with
meson.

> I obviously could not verify binaries, but the files are at least
> present :)

Thanks for the feedback.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200717/5aa84c68/attachment-0001.sig>


More information about the libvir-list mailing list