Move all `@deprecated` stuff inside `GEANY_DISABLE_DEPRECATED` guards, and mark some with `G_GNUC_DEPRECATED` or G_GNUC_DEPRECATED_FOR`.
Apart that the code should not have been modified, but merely reordered.
Note: all PG seem to build just fine as of current master (e.g. not modified for the occasion). You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/911
-- Commit Summary --
* Move deprecated declarations inside GEANY_DISABLE_DEPRECATED guards * Mark deprecated API so GCC can warn about it
-- File Changes --
M src/plugindata.h (104) M src/sciwrappers.h (8) M src/ui_utils.h (7)
-- Patch Links --
https://github.com/geany/geany/pull/911.patch https://github.com/geany/geany/pull/911.diff
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911
Gonna be easy to miss deprecation warnings if mixed inside GTK3 deprecations noise though.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911#issuecomment-186714926
We should add the command to build without showing GLib deprecation warnings to the HACKING file and maybe the build system. IIRC it's something like `./configure CFLAGS="-DGLIB_DISABLE_DEPRECATION_WARNINGS"`. Assuming it won't hide our API deprecations.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911#issuecomment-186721264
@codebrainz good point. Meaningless deprecation hiding is now implemented in 409fe1a3234cf9e1fa74f81d1404fa3123e7c973 in this PR, please give it a look :)
I fixed a few things, and remove used some internal uses of the deprecated APIs.
However, some *sciwrappers* things are either hard-ish to get rid of, or worth to keep in some specific situations (at least some implementations). I'm not certain what to do, but probably keep them internally and simply deprecate the API part. How to do that then? only mark with `G_GNUC_DEPRECATED` when not building Geany? introduce alias names not part of the API for internal use?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911#issuecomment-188478136
I implemented our own versions of the macros in 527041e39c6c4a5b1bc1cd99cd4bd3af13a5df51 so we can enable them conditionally. This "fixes" the issue and seems nicer for everyone. With this, we might (or might not) want to revert a2d41c5dfa71508dda056d3182e874f1b825a8f3 which is kinda pointless now.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911#issuecomment-188492988
On 2016-02-24 02:15 PM, Colomban Wendling wrote:
How to do that then? only mark with `G_GNUC_DEPRECATED` when not building Geany? introduce alias names not part of the API for internal use?
Can use #pragma push/pop diagnostics thing around specific code to have finer grained control. Might be a hassle though since you can't hide the pragmas with convenient preprocessor macros (AFAIK).
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911#issuecomment-188549761
@codebrainz GLib has [`G_GNUC_BEGIN_IGNORE_DEPRECATIONS`](https://developer.gnome.org/glib/unstable/glib-Miscellaneous-Macros.html#G-G...) and [`G_GNUC_END_IGNORE_DEPRECATIONS`](https://developer.gnome.org/glib/unstable/glib-Miscellaneous-Macros.html#G-G...), but it's new in 2.32.
Anyway, I'm mostly comfortable not deprecating inside Geany as I did in 527041e39c6c4a5b1bc1cd99cd4bd3af13a5df51, which also has the advantage of allowing plugin code to also ignore them like we can for GLib and GTK. And I think it's not that much of a problem to manually track what we want to really remove from the core too.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911#issuecomment-188862078
Merged #911.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/911#event-573561382
github-comments@lists.geany.org