All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.