[Bug 49400] add GLib-2.32-style deprecation macros

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49400

--- Comment #21 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-05-03 03:23:52 PDT ---
(In reply to comment #12)
> 2/9] Ignore deprecation of TpChannelFactoryIface when calling  its methods
...
> Are we getting rid of this in 'next'?

It already went away.

(In reply to comment #13)
> Do we really still need TP_DISABLE_DEPRECATED?

It's the only way to "deprecate" macros (and typedefs/enums, unless we add a
gcc-specific version of _TP_DEPRECATED_IN_x_y), and it seems sensible to make
it act on everything.

_TP_DEPRECATED and _TP_DEPRECATED_IN_x_y (and the GLib macros they're based on)
are portable (to at least MSVC), but have to appear before a function; they
can't appear after, and can't go on typedefs or enums or whatever.

(In MSVC they're implemented as __declspec(deprecated) or something, which can
only appear on extern symbols - ABI, not API.)

_TP_GNUC_DEPRECATED (and the GLib macro it's based on) is gcc-only, but more
flexible.

None of those work on macros, because macros are expanded before the compiler
gets involved.

(In reply to comment #20)
> We should at least annotate the new 0.19 API for MAX_ALLOWED.

Yes. May I merge this lot first?

> Btw, would it be possible to raise an error during 'make check' if a new API is
> added without its version annotation?

I can't think of an easy way to do so. I don't want to write yet another
semi-working C parser (we run two of those already, in gtk-doc and g-i).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.