qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Snow
Subject: Re: [Qemu-devel] [PATCH 2/2] Compile time checks for newer glib
Date: Mon, 01 Jun 2015 14:01:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0


On 05/29/2015 12:01 PM, Dr. David Alan Gilbert wrote:
> * Peter Maydell (address@hidden) wrote:
>> On 29 May 2015 at 16:01, Dr. David Alan Gilbert (git)
>> <address@hidden> 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 / address@hidden / 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]