Make API versioning compiler evaluable

classic Classic list List threaded Threaded
2 messages Options
Jan-Marek Glogowski Jan-Marek Glogowski
Reply | Threaded
Open this post in threaded view

Make API versioning compiler evaluable

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...

LibreOffice mailing list
[hidden email]

since-grep-unique.log (2K) Download Attachment
Michael Stahl-3 Michael Stahl-3
Reply | Threaded
Open this post in threaded view

Re: Make API versioning compiler evaluable

On 11.04.19 09:32, Jan-Marek Glogowski wrote:
> * Has UDK an independent versioning, or is it also the Office version?

it used to have independent versioning in OOo days, although looking at
@since tags in include/rtl that is evidently replaced by LO versioning now.

> More comments?

i'm not sure if it is worth the effort - we generally discourage C++
extensions anyway since Java or Python extensions have a lot less
pitfalls; Java doesn't have a preprocessor, and so the way to build
against an old API is to just put a corresonding old jar on the
classpath; Python doesn't even have static typing so it's not applicable.

also, if you look at the URE headers, almost any new addition in the
last years is behind #ifdef LIBO_INTERNAL_ONLY anyway.
LibreOffice mailing list
[hidden email]