[Bug 451093] New: 'showdeps' sucks heaps

["GARNOME (bugzilla.gnome.org)" <bugzilla-daemon bugzilla gnome org>]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=451093

  GARNOME | general | Ver: unspecified
           Summary: 'showdeps' sucks heaps
           Product: GARNOME
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: minor
          Priority: Normal
         Component: general
        AssignedTo: garnome-maint gnome bugs
        ReportedBy: guenther rudersport de
         QAContact: garnome-list gnome org
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=451093.