GNOME Bugzilla – Bug 358126
showdeps needs a MAXDEPTH parameter
Last modified: 2007-06-26 00:28:25 UTC
Please describe the problem: Showdeps eventualy will stop without a MAXDEPTH parameter Steps to reproduce: 1. make showdeps 2. and wait, wait, wait.. 3. Actual results: It didn't stop after 1 hour of 100% of CPU. The 'make' depth was about 17 .. Expected results: Does this happen every time? Other information: Catching and analyzing those deps it's clear that showdeps is getting into depencency circles
Created attachment 73557 [details] [review] MAXDEPTH parameter to showdeps $ make showdeps ** showdeps WARNING ** Specify a MAXDEPTH value, e.g. make MAXDEPTH=2 showdeps It's needed to avoid running forever make[2]: ** [showdeps] Erro 1
Sorry, maybe not gettin into 'dependency circles' but going donw several times through a same path.. And someone else please suggests me a more polite and correct message ! tnks
Nope, showdeps will *not* get into any circles. Any circle would mean an infinite loop -- and thus install would be broken, too. Anyway... I agree that showdeps is quite dumb. However, it's intention is to check all deps for a *particular* garball. Running this for every single garball is quite insane... ;) I'm not sure if an enforced MAXDEPTH parameter is the correct approach here. Your goal is to gather the data necessary to generate a nice dep graph. Which basically is maxdept=2 always -- the garball itself plus the LIBDEPS, not descending at all. Recursive calls of make don't remember easily the garball it already touched. Thus, IMHO, a better approach is this: * A new target, that spews the direct LIBDEPS only. * A script, that uses this data. Maybe even not calling make at all, but using a script that recursively checks all Makefiles itself. This will be way faster even. Rejecting the patch, cause it *enforces* a MAXDEPTH parameter.
Lucas, how is this OBSOLETE? [1] If this simply happens to be "obsolete" for you, INCOMPLETE would have been better. According to my comment 3, this actually should be NOTABUG anyway (which means, that the behavior is a design choice, which it is.) [1] In bugzilla lingo this means, that the reported issue doesn't apply to the current code, but the originally reported issue has not been fixed.
Lucas, see bug 451093 for a rewritten 'showdeps' implementation, that terminates quickly, reports all deps, and does not need to be forced to stop at any level (which resuls in deps not being reported).