After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 552066 - Need to handle deprecated code inside #ifndef GTK_DISABLE_DEPRECATED
Need to handle deprecated code inside #ifndef GTK_DISABLE_DEPRECATED
Status: RESOLVED OBSOLETE
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other All
: Normal enhancement
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-09-13 03:48 UTC by Mike Kestner
Modified: 2018-02-08 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
parse gtk-doc Deprecated (7.41 KB, patch)
2008-09-14 23:16 UTC, Colin Walters
none Details | Review
include full deprecation information (10.83 KB, patch)
2008-09-15 13:14 UTC, Colin Walters
none Details | Review
split out version (11.30 KB, patch)
2008-09-15 14:35 UTC, Colin Walters
committed Details | Review
Parse deprecated/deprecated_for macros (12.19 KB, patch)
2011-11-08 01:39 UTC, Johan (not receiving bugmail) Dahlin
none Details | Review
Parse deprecated/deprecated_for macros (21.87 KB, patch)
2011-11-08 22:53 UTC, Johan (not receiving bugmail) Dahlin
none Details | Review

Description Mike Kestner 2008-09-13 03:48:00 UTC
Please describe the problem:
GtkArg for example carries no indication of its deprecated status.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Colin Walters 2008-09-14 23:16:04 UTC
Created attachment 118713 [details] [review]
parse gtk-doc Deprecated
Comment 2 Colin Walters 2008-09-14 23:18:02 UTC
There are multiple parts to support here - GtkArg is actually somewhat tricky because it's a pure structure definition in the .h file, under #ifndef GTK_DISABLE_DEPRECATED.  For functions and the like, the way this is specified is in the gtk-doc with a Deprecated: tag.  The above patch parses that, but does not attempt to handle the header.
Comment 3 Johan (not receiving bugmail) Dahlin 2008-09-15 12:54:40 UTC
(In reply to comment #1)
> Created an attachment (id=118713) [edit]
> parse gtk-doc Deprecated
> 

Looks pretty good I wouldn't mind having this committed as is, however:
 - Does it make sense to include the version it was deprecated in?
 - Separating annotation parsing from normal parsing would be useful, 
   so it can be enabled/disabled by a command line parameter in the future
 - Moving more of the gtk-doc parsing to python would make sense here.


Comment 4 Colin Walters 2008-09-15 13:14:59 UTC
Created attachment 118744 [details] [review]
include full deprecation information

This patch includes both the version and the comment (see the diff to annotation-expected.gir).
Comment 5 Colin Walters 2008-09-15 13:15:33 UTC
(In reply to comment #3)

>  - Separating annotation parsing from normal parsing would be useful, 
>    so it can be enabled/disabled by a command line parameter in the future
>  - Moving more of the gtk-doc parsing to python would make sense here.

All for that, but I am not very familiar with the code and unsure how to do so.
Comment 6 Johan (not receiving bugmail) Dahlin 2008-09-15 13:21:57 UTC
(In reply to comment #4)
> Created an attachment (id=118744) [edit]
> include full deprecation information
> 
> This patch includes both the version and the comment (see the diff to
> annotation-expected.gir).  

I'd prefer separate tags, so users of the gir doesn't have to do any extra string parsing to get that information. Better to do a bit of more work in the scanner to make the life easier for gir users.

(In reply to comment #5)
> (In reply to comment #3)
> 
> >  - Separating annotation parsing from normal parsing would be useful, 
> >    so it can be enabled/disabled by a command line parameter in the future
> >  - Moving more of the gtk-doc parsing to python would make sense here.
> 
> All for that, but I am not very familiar with the code and unsure how to do so.

Neither am I, I guess this can wait. I just know that the C parsing code is fragile and that I personally would much rather use Python to do that.
Comment 7 Colin Walters 2008-09-15 14:35:07 UTC
Created attachment 118758 [details] [review]
split out version
Comment 8 Johan (not receiving bugmail) Dahlin 2008-09-15 14:42:34 UTC
Comment on attachment 118758 [details] [review]
split out version

>diff --git a/giscanner/ast.py b/giscanner/ast.py
>     def __init__(self, name=None):
>         self.name = name
>+        self.deprecated = None

It would make more sense to add deprecated_version here (or perhaps deprecated_since)...

>diff --git a/giscanner/girwriter.py b/giscanner/girwriter.py

>+    def _append_deprecated(self, node, attrs):
>+        if node.deprecated:
>+            (deprecated_version, deprecated_str) = node.deprecated

...  then you would avoid this.

>+            attrs.append(('deprecated', deprecated_str.strip()))
>+            if deprecated_version:
>+                attrs.append(('deprecated-version',
>+                              deprecated_version.strip()))

strip():ing should be done in the parsing, not in the wriring.


>diff --git a/giscanner/transformer.py b/giscanner/transformer.py

>+            try:
>+                # Split out gtk-doc version
>+                func.deprecated = deprecated[0].split(':', 1)
>+            except ValueError, e:
>+                # No version, just include str
>+                func.deprecated = (None, deprecated[0])

I usually prefer to do a if ':' in deprecated, but it's not a big deal, do as you like.

>+    <function name="object_do_not_use"
>+              c:identifier="annotation_object_do_not_use"
>+              deprecated="Use annotation_object_create_object() instead."
>+              deprecated-version="0.12">

Looks good!

You can commit this if you address the comments above.
Comment 9 Colin Walters 2008-09-15 15:19:46 UTC
Reopening this bug until we also correctly handle #ifndef GTK_DISABLE_DEPRECATED.
Comment 10 Lucas Hermann Negri 2009-03-05 03:09:48 UTC
It would be nice to have deprecated classes marked as deprecated too, not only functions.
Comment 11 Johan (not receiving bugmail) Dahlin 2011-11-08 01:39:24 UTC
Created attachment 200949 [details] [review]
Parse deprecated/deprecated_for macros
Comment 12 Johan (not receiving bugmail) Dahlin 2011-11-08 16:45:43 UTC
I have a patch at my laptop at home which adds the following on top of attachment 200949 [details] [review]

deprecated -> c:deprecated-for
deprecated-version -> c:deprecated-version
new attribute: c:deprecated, 0 is default, 1 means the functions is deprecated, similar to what we have in the tgir

No girepository/typelib changes will be necessary.
Comment 13 Johan (not receiving bugmail) Dahlin 2011-11-08 22:53:32 UTC
Created attachment 201032 [details] [review]
Parse deprecated/deprecated_for macros
Comment 14 André Klapper 2015-02-07 17:17:30 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
Comment 15 GNOME Infrastructure Team 2018-02-08 11:44:22 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/1.