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.