[libvirt PATCH v2 00/56] the gnulib saga: the season finale

Pavel Hrdina phrdina at redhat.com
Tue Jan 28 13:35:09 UTC 2020


On Tue, Jan 28, 2020 at 01:10:41PM +0000, Daniel P. Berrangé wrote:
> This is a followup to
> 
>   v1: https://www.redhat.com/archives/libvir-list/2020-January/msg00900.html
> 
> At the end of this series we have 100% eliminated use of GNULIB
> from libvirt.
> 
> The first 10 or so patches have been reviewed by Pavel already
> but I include them here anyway. Rather than wait for all of
> the series to be review, it is probably more productive to
> push patches in batches of 10 or so.
> 
> Some things to note
> 
>  - I have build tested this on Travis platforms and manually
>    via FreeBSD 11/12. This covers make, make syntax-check &
>    make check
> 
>  - I've validated that virsh still works with mingw64 builds
>    on Windows 2008r2.
> 
>  - I've done basic functional testing on Fedora 31, starting
>    and stopping VMs & other other simple APIs
> 
> The config.h we generate is much much smaller than before as we
> eliminated alot of gnulib macros.
> 
> The risk here is that we are no longer setting some HAVE_XXX
> in config.h that we rely on. To mitigate this I did a diff
> of config.h before & after this series to determinw which
> HAVE_XXX we no longer set. I then grepped the source to see
> if we actually use any of them. This identified a few mistakes
> which I fixed in testing this series.
> 
> The builds times for libvirt after applying this series have
> some significant gains, improving speed of all stages (autogen,
> configure & make).
> 
> Overall while this was time consuming work (due to massive number
> of builds for testing each step), it is surprising just how easy
> it was eliminate need for GNULIB.  GLib helped a little bit in
> this respect, but the biggest factor is simply that a large
> number of issues GNULIB fixes only matter for ancient / obsolete
> OS platforms.
> 
> With libvirt only targetting modern Linux, FreeBSD, macOS & MinGW,
> the only really hard stuff where GNULIB was a big help is the
> Windows sockets portability.
> 
> GNULIB was a pretty valuable approach when there were countless
> flavours of UNIX to worry about with poor levels of POSIX API
> compatibility. With a typical modern set of platforms, I think
> it is better to just use a library like GLib and deal with any
> other portability problems explicitly.
> 
> Almost certainly someone will appear after next release and
> complain that libvirt no longer builds on some platform that
> we don't officially support. My expectation is that when this
> happens it will be reasonably easy to fix whatever problem
> they report. Also at that time we can also consider whether
> the platform needs to be added to CI.

Awesome job, I'll continue with review so that we can get this pushed
ASAP and continue with conversion to Meson which I'm working on in the
mean time to split it into patches.

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/20200128/ba3c7826/attachment-0001.sig>


More information about the libvir-list mailing list