qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	Eric Blake <eblake@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Peter Xu <peterx@redhat.com>, Olaf Hering <olaf@aepfle.de>,
	Stefan Berger <stefanb@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v2 2/3] glib: enforce the minimum required version and warn about old APIs
Date: Thu, 7 Jun 2018 10:23:13 +0100	[thread overview]
Message-ID: <20180607092313.GG28827@redhat.com> (raw)
In-Reply-To: <75dd4f2c-e564-5557-8ccb-66857a7afafd@redhat.com>

On Thu, Jun 07, 2018 at 10:57:56AM +0200, Thomas Huth wrote:
> On 06.06.2018 19:32, Daniel P. Berrangé wrote:
> > There are two useful macros that can be defined before including
> > glib.h that are related to the min required glib version
> > 
> >  - GLIB_VERSION_MIN_REQUIRED
> > 
> >    When this is defined, if code uses an API that was deprecated
> >    in this version, or older, a compiler warning will be emitted.
> >    This alerts maintainers to update their code to whatever new
> >    replacement API is now recommended best practice.
> > 
> >  - GLIB_VERSION_MAX_ALLOWED
> > 
> >    When this is defined, if code uses an API that was introduced
> >    in a version that is newer than the declared version, a compiler
> >    warning will be emitted. This alerts maintainers if new code
> >    accidentally uses functionality that won't be available on some
> >    supported platforms.
> > 
> > The GLIB_VERSION_MAX_ALLOWED constant makes it a bit harder to opt
> > in to using specific new APIs with a GLIB_CHECK_VERSION conditional.
> > To workaround this Pragmas can be used to temporarily turn off the
> > -Wdeprecated-declarations compiler warning, while a static inline
> > compat function is implemented. This workaround is illustrated with the
> > implementation of the g_strv_contains method to satisfy the test suite.
> 
> I wonder whether that's a little bit too much magic already. We could
> also set GLIB_VERSION_MAX_ALLOWED to the version where we've already got
> the work-arounds in place (i.e. to 2.44 here). If we introduce
> additional code that uses other new functions from 2.41 - 2.44, this
> should also be caught by the patchew CI builders?

I don't think that's a good direction to take - if we follow that
through and someone backports a function from 2.56, we'll loose
100% of the benefit of the MAX_ALLOWED checking. Given we only have
a handful of backported functions, that is not a good tradeoff.


> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >  include/glib-compat.h                    | 67 ++++++++++++++++++++++++
> >  tests/docker/dockerfiles/centos6.docker  | 30 -----------
> >  tests/docker/dockerfiles/min-glib.docker |  8 ---
> 
> The docker files are not directly related to this patch, are they? If
> they are, please mention it in the patch description. If not, please
> move this to a separate patch (or maybe into patch 1).

Yeah should go in the patch that bumps the min version really.


> > +/* Ask for warnings for anything that was marked deprecated in
> > + * the defined version, or before. It is a candidate for rewrite.
> > + */
> > +#define GLIB_VERSION_MIN_REQUIRED GLIB_VERSION_2_40
> > +
> > +/* Ask for warnings if code tries to use function that did not
> > + * exist in the defined version. These risk breaking builds
> > + */
> > +#define GLIB_VERSION_MAX_ALLOWED GLIB_VERSION_2_40
> > +
> > +_Pragma("GCC diagnostic push")
> > +_Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
> 
> Why not "#pragma" ? I think that's a little bit more common?

I tend to always use _Pragma as that offers superset of functionality
of #pramga, because _Pragma can be used in macros.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2018-06-07  9:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-06 17:32 [Qemu-devel] [PATCH v2 0/3] glib: update the min required version Daniel P. Berrangé
2018-06-06 17:32 ` [Qemu-devel] [PATCH v2 1/3] glib: bump min required glib library version to 2.40 Daniel P. Berrangé
2018-06-06 18:12   ` John Snow
2018-06-07  8:25     ` Daniel P. Berrangé
2018-06-07  8:28       ` Olaf Hering
2018-06-08 13:13         ` Daniel P. Berrangé
2018-06-07  5:46   ` Thomas Huth
2018-06-06 17:32 ` [Qemu-devel] [PATCH v2 2/3] glib: enforce the minimum required version and warn about old APIs Daniel P. Berrangé
2018-06-07  8:57   ` Thomas Huth
2018-06-07  9:23     ` Daniel P. Berrangé [this message]
2018-06-06 17:32 ` [Qemu-devel] [PATCH v2 3/3] util: remove redundant include of glib.h Daniel P. Berrangé
2018-06-06 17:45   ` Philippe Mathieu-Daudé
2018-06-06 18:31   ` Peter Maydell
2018-06-07  3:58     ` Peter Xu
2018-06-07  7:05       ` Markus Armbruster
2018-06-07  7:44         ` Peter Xu
2018-06-07  8:26           ` Daniel P. Berrangé
2018-06-07  8:35             ` Peter Xu
2018-06-07  8:44   ` Thomas Huth
2018-06-07  8:47     ` Daniel P. Berrangé
2018-06-08 12:00 ` [Qemu-devel] [PATCH v2 0/3] glib: update the min required version Peter Maydell
2018-06-08 16:18   ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180607092313.GG28827@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=olaf@aepfle.de \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanb@linux.vnet.ibm.com \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).