Ignore "deprecation guards"
The "deprecation guards" pre-processor macros as used by ancient GLib and GTK releases, like:
#ifndef FOO_DISABLE_DEPRECATED void foo_object_set_attribute (FooObject *self, int attribute); int foo_object_get_attribute (FooObject *self); #endif
have been progressively replaced by per-symbol, versioned deprecation annotations, like:
FOO_DEPRECATED_IN_1_4_FOR (foo_object_set_int_attribute) void foo_object_set_attribute (FooObject *self, int attribute); FOO_DEPRECATED_IN_1_4_FOR (foo_object_get_int_attribute) int foo_object_get_attribute (FooObject *self);
There are many advantages to the latter format—most importantly, that compiler warnings are more fine grained than removing symbols from public headers, and let projects deal with deprecations on their own terms.
The annotations are more complicated to parse, and gtk-doc does not know how to handle them, so we're getting warnings that a
Deprecated attribute in the documentation stanza does not match the deprecation guard.
The warning itself is kind of inconsequential: the symbol gets deprecated anyway.
At this point, the old style deprecation guards are just a liability and a source of warnings during builds. GTK-Doc should ignore them, unless they are specifically declared, for backward compatibility; in other words, if
--deprecated-guards is not passed, GTK-Doc should only rely on the
Deprecated annotation to decide if a symbol is deprecated or not.