On Tue, 2019-10-15 at 18:21 +0100, Daniel P. Berrangé wrote:
On Tue, Oct 15, 2019 at 04:10:55PM +0200, Andrea Bolognani wrote:
> On Tue, 2019-10-15 at 14:21 +0200, Ján Tomko wrote:
> > -#define ARRAY_CARDINALITY(Array) (sizeof(Array) / sizeof(*(Array)))
> > +#define G_N_ELEMENTS(Array) (sizeof(Array) / sizeof(*(Array)))
>
> In this case, and in this case only, I think we should leave the name
> alone.
>
> When we use GLib and simply provide our own implementation when using
> a version that's too old, the GLib name is obviously accurate, but in
> this specific case I think it's misleading and we should stick with
> the current one.
We do have the option to have our example programs use GLib instead
of plain C. If people are using libvirt from plain C, I'm inclined
to suggest they'd be wise to use GLib for the same reasons that it
is beneficial for libvirt to use GLib.
If they're not using GLib, they likely have enough C knowledge to
figure out what they must do from our examples anyway.
Introducing a dependency on GLib for the example sounds acceptable
to me, and certainly better than defining G_* macros ourselves.
One thing we could do, and which would be useful in general as well
as being fairly common from what I've seen in other projects, is to
have a comment at the start of the example file along the lines of
/* event-test - listen to libvirt events
*
* Compile with:
*
* gcc -o event-test event-test.c \
* $(pkg-config --cflags --libs libvirt glib-2.0)
*/
At that point even people who are not that familiar with C, libvirt
or GLib will be able to build and run the example.
--
Andrea Bolognani / Red Hat / Virtualization