GNOME Bugzilla – Bug 451093
'showdeps' sucks heaps
Last modified: 2014-08-30 00:11:35 UTC
So, I added pygtksourceview and changed the LIBDEPS for gedit in SVN trunk, which now depends on the rewritten gtksourceview and its new API. Good. Got a little paranoid about recursion and quickly checked it. Or so I thought... The 'showdeps' hog went on and on. While it literally was burning my CPU, I checked the LIBDEPS in head, coming to the conclusion there can not possibly be a recursion. However, 'showdeps' just didn't terminate. Getting freaked out, I developed a few tricks to inspect the deps tree live, while it still was being generated. 'showdeps' was kind of stuck in gnome-python-desktop. Still no recursion, though... Eventually, after way past an hour (going from memory here) it *finally* terminated. Leaving 2.6 MByte of redirected output behind, no less than *73010* lines (read: deeply inspected LIBDEPS), for a total of 91 distinct garballs it depends on... The reason simply is, that 'showdeps' is dumb, empty-headed. For each LIBDEPS, it descends into all LIBDEPS, no matter if it has been there before or not. Some of them have been evaluated more than 5000 times. Something that *never* will happen when building, because GAR keeps precious cookies. To fix this, I implemented a version of 'showdeps', that never reports any garball twice, effectively resulting in a tree that shows the exact build order. Attaching a patch in a minute. This implementation returns after no more than 15 *seconds* for gedit (rather slow HDD, no state of the art CPU). And actually reports a total of exactly 92 lines (including this garball, too). Compare that to 'showdeps'. Seriously, just try it, run both. Downside: It creates cookies... Comments, thoughts? Sidenote: Cures any problem mentioned in bug 358126, too.
Created attachment 90643 [details] [review] 'tree' target, that re-implements 'showdeps' in a sensitive way
Got another implementation in the pipes. Similar to the above, however, reporting all deps for each garball *inside* the for loop (just like showdeps). This *will* report deps multiple times occasionally, but *not* descend the tree any further, if we have been there already. This potentially can be used to identify unnecessary, implicite LIBDEPS, or even to paranoidly check for recursion, introduced by new LIBDEPS. Not yet fully implemented, though. Needs further hacking and thorough testing for usefulness.
GARNOME has not seen any code changes since 2008: https://git.gnome.org/browse/archive/garnome/log This project is not under active development anymore and got recently archived in GNOME Git. It is currently unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. If you are interested in maintainership, inform https://mail.gnome.org/mailman/listinfo/desktop-devel-list