GNOME Bugzilla – Bug 782227
tests fail because `g_type_init` is deprecated
Last modified: 2017-05-14 21:47:10 UTC
(since the warnings are treated as errors) Solved as described here: - https://askubuntu.com/questions/262574/how-to-correct-glib-2-35-x-g-type-init-is-deprecated-error-when-compiling-from The patch is in the way...
Created attachment 351206 [details] [review] tests: fix the `g_type_init` deprecation warnings
By the way, `make distcheck` fails with the exact same error, but I'm not yet sure how to fix that.
These are not errors, just warnings. But Planner considers warnings as errors (strange but legal). So make some_targets fail. This is bug 703067.
Sure, but the tests fail because of those warnings-errors; it may be due to GCC's default behavior or whatever, and the proposed patch is to fix that in a clean way. Planner's own macros is another story: this Glib version check should be present anyways.
By the way, thanks for pointing this out: this is the same bug (but solved differently) https://bugzilla.gnome.org/show_bug.cgi?id=742488
Created attachment 351265 [details] [review] ‘g_type_init’ is deprecated This patch is simpler. Planner code does not have to remember GLib history. Current Planner have to cope with current GLib. g_init() story is dead years ago, it is not actual.
Yes it doesn't have to. But then one should update the configuration scripts checking glib version too, not just remove those calls from the C files and imply that Planner cannot compile with an ancient versions of glib :)
*** Bug 742488 has been marked as a duplicate of this bug. ***
Who is wasting time compiling new Planner with old Gnome/GTK+/GLIb ? Planner is in bad need of such expertise. But he should reverse his path. The situation is worse than : "Oh, external libraries changed... Planner has to take care of that". It is : "Planner does not fit the current Gnome environment". It lags years of coding behind.
I don't really care how it will be resolved as long as it will, but general idea is that when one changes the interface so that it is no longer compatible with an older versions of a library used, it's probably wise to update the stated (version) requirements too. While just saying "it's so old nobody ever going to notice the difference" is probably not. Even README says "GLIB 2.6.0" -- fix that, and configure.ac, of leave the if-macros.
I agree : It has to be solved. It should have been. There is two threads here. One has to separate them. Comment 2, introduced a bug in a bug using the "By the way" formula. The Planner Bugzilla has got a Build Component (https://bugzilla.gnome.org/buglist.cgi?component=Build&product=planner). Bug 782227, comment 4 : Warnings turned to errors is by no way some default behavior. It is deliberate : acinclude.m4, line 47. $ grep -n 'Werror' acinclude.m4
- the error in distcheck I mentioned isn't solved by either of the patches proposed so far - Werror as such should probably not be removed, it doesn't break anything else - upgrading the interface to at least Glib 2.35.0, and not inserting the macros, is a better solution -- cleaner and solves the "side bug" without hassle - but it is a little bit more work to do than there is in your patch: `grep -R g_type_init .` and `grep -R 2.6.0 .` (from the sources' root) PS: I personally have no intentions for an exhaustive solution at the moment
The "make distcheck" failure is another bug. This is bug 782227. The title is : tests fail because `g_type_init` is deprecated. The "warnings are errors" is not a bug, it is a choice. make, make check succeed without changing any code, just by configuration. $ ./configure --enable-compile-warnings=no $ make ; make dist My patch doe not correct an inexistent bug. It cleans up the code, preparing the transition to GNOME 3.
Call it a failure or issue instead of a bug, the meaning is the same (and I don't want to discuss it here, move on if you disagree). Those warnings exist for a reason and should be fixed too, not just disabled (if disabled then temporarily, not committed). And you should do that in a consistent way (see above). No need to repeat the title to me, do you think I am unaware? The only reason I keep talking about the distcheck warning-error is because it's the only advantage of upgrading to a new glib I see, in what you state you are trying to do. And, by the way, transition to GNOME 3 is much much more work to do than just cutting out four or five function calls, as far as I can tell. But sure you know all of that. PS: it's getting increasingly harder for me to restrain myself from an ad hominem, I feel like this is what you are trying to do too. Why don't you talk about the modifications to your patch I'm pointing you to, instead of trying to make me a fool? You are free to leave the last comment.
To restate my point: the (exact) issue/bug may be solved two ways: 0. minimal way: leaving the required glib version intact but wrapping the version-specific code into a macros, so that it doesn't trigger the warnings on newer systems 1. exhaustive way: update the required glib version to a newer one (>= 2.35), and simply remove the obsolete code, so that it (even theoretically) simply refuses to build with an older glib The former is simpler. -- The latter is better, but needs to update README, configure.ac, and maybe some other files referring to the older version of Glib (>= 2.6.0).
Created attachment 351327 [details] [review] required Glib 2.35, to clean up g_type_init calls
PS: Sure one might just squash these two patches. But it's possibly better to retain the intermediate step than save one log entry.
Review of attachment 351327 [details] [review]: You should not remove the SCANGOBJ_OPTIONS variable in docs/libplanner/Makefile.am. The GTK-Doc makefile is quite standard, it is a template from https://git.gnome.org/browse/gtk-doc/tree/examples/Makefile.am. Something as simple, as : @@ -13 +13 @@ DOC_SOURCE_DIR=../../libplanner -SCANGOBJ_OPTIONS=--type-init-func="g_type_init()" +SCANGOBJ_OPTIONS= is enough. Source : https://developer.gnome.org/gtk-doc-manual/unstable/settingup_automake.html.en
Created attachment 351345 [details] [review] required Glib 2.35, to clean up g_type_init calls
(In reply to Andrew Miloradovsky from comment #19) > required Glib 2.35 Can you make that 2.36 by the way? 2.35 is an unstable release (odd number).
Created attachment 351346 [details] [review] required Glib 2.36, to clean up g_type_init calls
Review of attachment 351346 [details] [review]: The situation : make check fails. calendar-test.c:20:9: error: ‘g_type_init’ is deprecated cc1: all warnings being treated as errors Applying patches 351206 and 351346 : make check succeeds. The patches do the job. They are neat. +1, though I'd prefer them squashed.
You may think of the former patch as the minimally necessary solution. And the latter as being a cleanup, unrelated to a particular bug/issue.
Review of attachment 351206 [details] [review]: That would be the way to go if we cared about keeping compatibility with a very ancient version of glib. Given how old even 2.36 is, we don’t really care in this instance, not even to have that in the git history.
Review of attachment 351265 [details] [review]: Yes, that’s the way to go. This patch lacks documentation update though.
Review of attachment 351346 [details] [review]: Yep, since we don’t care about the previous patch this one is based on, that would be good if it applied on master. So either update this one (to squash it with previous one as Ahmed suggests) or update Ahmed’s patch with the bits that are here and not there.
Apparently I cannot disable notifications about this particular "bug", I don't believe it needed 26 comments. -- Do whatever you prefer. I don't really care whose name will be shown on the commit, if ever. And I'm not going to follow the thread anymore.
(In reply to Andrew Miloradovsky from comment #27) > Apparently I cannot disable notifications about this particular "bug", You should have been able to do it. One has to click “Edit” next to the CC list, select the relevant address and check “Remove selected CC”. > I > don't believe it needed 26 comments. -- Do whatever you prefer. I don't > really care whose name will be shown on the commit, if ever. Well it sure wasn’t a very complex issue, but even after those 26 comments the patches weren’t ready… We’re getting there though! > And I'm not > going to follow the thread anymore. I unsubscribed you.
Created attachment 351842 [details] [review] g_type_init() has been deprecated since GLib 2.36. Removed attachment 351265 [details] [review]. Squashed attachment 351206 [details] [review] and attachment 351346 [details] [review]. Changed the commit message a little. The author remains Andrew.
Review of attachment 351206 [details] [review]: Obsoleted by attachment 351842 [details] [review].
Review of attachment 351346 [details] [review]: Obsoleted by attachment 351842 [details] [review].
Review of attachment 351842 [details] [review]: Thanks to you both, pushed.