On 1/9/19 7:33 AM, Andrea Bolognani wrote:
On Tue, 2019-01-08 at 13:56 -0600, Eric Blake wrote:
My recent patch to make all of the examples work independently of gnulib worked fine on Linux, but failed on mingw: https://travis-ci.org/libvirt/libvirt/jobs/476898635
The whole point of gnulib is to work around portability pitfalls so we don't have to bend over backwards thinking about it in our code; and it would be possible to fix this bug by linking the problematic example binaries against gnulib after all. But since the examples are still small and self-contained enough that using manual workarounds wasn't too daunting, that's the approach I took here.
It's kind of a done deal now, but I still wonder if it was the right approach.
The way I see it, our examples are supposed to illustrate how to use libvirt itself, not how to write C code that is portable to a multitude of platforms: with that goal in mind, taking advantage of gnulib makes perfect sense, as it allows us to put the focus on the usage of libvirt rather than the surrounding compatibility gunk.
Not everyone that would write to libvirt API's would have installed gnulib. Asked differently, is having gnulib installed a prerequisite for having libvirt installed? What about libvirt-devel? While altering these examples to adhere to some least common denominator architecture is perhaps less optimal - it does show one can generate architecture agnostic examples as long as they understand issues surrounding portability. An alternative one could generate patches for would be #ifdef'd code or perhaps even simply comments indicating the alternative methodology that is less portable. For those without git history it's perhaps harder to figure out. John
I would probably have a different opinion about this if the workarounds were related to eg. using certain types as opposed to others when passing data to libvirt functions, but as far as I can tell that's not the case.