Re: [Qemu-devel] [PATCH 2/2] Compile time checks for newer glib

[John Snow <jsnow@redhat.com>]

On 05/29/2015 12:01 PM, Dr. David Alan Gilbert wrote:
> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> On 29 May 2015 at 16:01, Dr. David Alan Gilbert (git)
>> <dgilbert@redhat.com> wrote:
>>> --- a/include/glib-compat.h
>>> +++ b/include/glib-compat.h
>>> @@ -16,6 +16,12 @@
>>>  #ifndef QEMU_GLIB_COMPAT_H
>>>  #define QEMU_GLIB_COMPAT_H
>>>
>>> +/*
>>> + * The source file including this compat header knows it's using newer glib
>>> + * functions than we generally allow, so don't warn about it.
>>> + */
>>> +#undef GLIB_VERSION_MIN_REQUIRED
>>> +#undef GLIB_VERSION_MAX_ALLOWED
>>>  #include <glib.h>
>>
>> ...but glib-compat.h is included by qemu-common.h and in general
>> the point is that code anywhere in QEMU can assume the compat
>> versions exist, so it feels like this will defeat the point.
> 
> Hmm, a lot of files seem to include glib.h directly.  But OK,
> so then Paolo is suggesting setting the minimum to 2.32
> which I can do, but then that wouldn't stop something that's
> in 2.22-2.32 but not in glib-compat.h
> 
> Dave
> 
>>
>> -- PMM
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
> 

When I bumped glib to 2.22, I played with using these macros and forcing
all files to include glib-compat and prohibiting direct includes of glib.

The problem is without a minimum version set to 2.3x, as you've stated,
the deprecated warnings will trigger for functions we added explicit
compat wrappers for, and I could think of no sane way to "forgive" these
usages as a one-time exception.

Perhaps -- /perhaps/ -- you could have a qemu-internal glib.h that sets
the version warnings and leave glib-compat alone without those includes,
but this seems like a setup that is inviting frustration for future devs.

--js