[libvirt] [PATCH 0/3] Fix examples/ under mingw

[John Ferlan]

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.
>