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