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

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.