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. > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
