Make API versioning compiler evaluable

Jan-Marek Glogowski glogow at
Thu Apr 11 07:32:27 UTC 2019

Hi everyone,

while discussing, I realized that we
have actually extended API documentation using @deprecated and @since (which I
knew), but I don't know a way to automatically check them. Maybe I'm just
unaware, but I also couldn't find anything, neither via Web search nor various
greps on the code base.

Using opengrok I got "Searched full:deprecated" = 593 and "Searched full:"@
deprecated"" = 348. And while at it "Searched full:since" = 2959 and "Searched
full:"@ since" = 1447. So massive info is there :-)

IMHO we want to introduce something like glib/gversionmacros.h (see the end of Nobody can
manually verify the use of deprecated or introduced functions with regard to the
version (@deprecated is sadly currently unversioned).

I was just aware of G_DISABLE_DEPRECATED, which glib / gtk has "since ever". Now
I found there also is (and we should use) GLIB_VERSION_MIN_REQUIRED and
GLIB_VERSION_MAX_ALLOWED. I was already bitten by not using this, when I checked
in the timer changes for the VCL gtk backend and found that our baseline glib
was too old, after pushing it.

Some questions that came to my mind:
* Has UDK an independent versioning, or is it also the Office version?
* Does anybody have a sensible idea to generate macros from docs or the other
way around?
* Is this easyhackable, if the required infrastructure is in place?
* Any good idea to automatically version the @deprecated?

More comments?


P.S. there are some funny @since, like "@since #i39203#". I've attached a "git
grep '@since' | sed 's/^[^@]*//' | sort -u". The 2007 dates are from
reportbuilder/java/org/libreoffice/report/pentaho/. The rest looks promising.
P.P.S. that would have been something for GSoC...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: since-grep-unique.log
Type: text/x-log
Size: 2164 bytes
Desc: not available
URL: <>

More information about the LibreOffice mailing list