Summary: | G_HAVE_INLINE no longer exists in GLib 2.47.2 | ||
---|---|---|---|
Product: | dbus | Reporter: | Colin Watson <cjwatson> |
Component: | GLib | Assignee: | D-Bus Maintainers <dbus> |
Status: | RESOLVED FIXED | QA Contact: | D-Bus Maintainers <dbus> |
Severity: | normal | ||
Priority: | medium | Keywords: | patch |
Version: | git master | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | review+ | ||
i915 platform: | i915 features: | ||
Attachments: | [PATCH] Stop using G_HAVE_INLINE |
Description
Colin Watson
2015-12-26 23:43:15 UTC
(In reply to Colin Watson from comment #0) > (Yes, I know that dbus-glib is deprecated. It's not my code that I'm trying > to build, and the code in question uses -Werror ...) Presumably this means you would oppose my (semi-serious) plan to mark every symbol in dbus-glib as G_GNUC_DEPRECATED? I would strongly recommend not using -Werror in code that still uses dbus-glib. I would also recommend not using dbus-glib, but I know from Telepathy that switching APIs is hard. I'm a little concerned that this patch is going to break ye olde compilers, in which inline is not necessarily defined or functional - you have to use __inline in ISO C89 compilers, like gcc -std=c89 and older MSVC. For dbus-glib itself we can use AC_C_INLINE to be immune to this, and with GLib >= 2.47.2 we can assume that GLib will define inline to __inline for us, but the sort of people who are using a compiler from the previous century will probably also not be using bleeding-edge GLib. I think we can fix this by using G_CAN_INLINE like we were meant to do all along. (In reply to Simon McVittie from comment #1) > I'm a little concerned that this patch is going to break ye olde compilers Actually, it's fine: <glib/gutils.h> defines inline to __inline or __inline__ or nothing, if necessary, and has done so for 15 years. Thanks, applied your patch. It will be in 0.106 when I get round to it. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.