Compile-time dependency loops can produce compile warnings

RESOLVED FIXED in Bugzilla 3.0

Status

()

defect
--
major
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: mkanat, Unassigned)

Tracking

2.21
Bugzilla 3.0
Dependency tree / graph

Details

Attachments

(2 attachments, 1 obsolete attachment)

module A does a "use" on module B.
module B does a "use" on module A.

mod_perl breaks, and perl -wc on either module A or B will produce a lot of
"subroutine redefined" warnings.

There are various ways to fix this:

1) Check @INC if this module is already loaded, and don't load it if so. If we
can do this simply, this is preferred since it's the most modular solution.
However, it may not be possible.

2) Remove most "use" statements from libraries, and then re-order the "use"
statements in CGIs so that the least-dependent things are first and the
most-dependent things are last.

3) Move around a bunch of subroutines to eliminate dependency loops.

Right now, this is a HUGE problem for us -- we have a LOT of dependency loops.
We may want to fix the problem in several smaller bugs that block this bug.

As we're doing this, we'll have to set rules on certain libraries as to what
they can "use." There should be many libraries that say, "This library may not
'use' anything in the Bugzilla namespace."
Depends on: 304600
Depends on: 304601
Actually, we don't have as many dependency loops as we thought.

Most of them disappeared with the checkin of bug 303413.

Check the graph at http://www.justdave.net/BugzillaDeps.png

Notice except for the 2 red lines we already knew about that all of the arrows
point to the right.  There are none going directly up/down, and none pointing
left.  This is a Good Thing. :)

So our only problems in the way of dependency loops now are:
Bugzilla::Attachment <-> Bugzilla::Flag
and
Bugzilla::Util <-> Bugzilla::Error
Depends on: 304653
Posted file Perl module dependency grapher (obsolete) —
Here's a more-capable version of the module dependency graph creator that I
posted to the other bug.  This one completely parses out the pod docs, as well
as having cross-dependency testing which turns the lines red if two modules
cross-depend on each other (but it doesn't actually do loop checks yet).
And the current dependency graph, just for posterity.
Depends on: 304699
This should be added to our test suite and throw a "not ok" for each
interdependency.
Updated grapher script.  This one detects all loops, not just direct cross-dependencies.  It also properly deals with all current known instances of modules being loaded from a variable name (which in itself exposed several additional loops).
Attachment #192693 - Attachment is obsolete: true
We should probably use that code as a base for bug 304600.

Note that for the most part it's okay if a module "uses" one module, and that module "requires" it in return, since those will happen at different times. It's not okay for two modules to "require" each other, or two modules to "use" each other.
Summary: Dependency loops will break mod_perl and produce compile warnings → Compile-time dependency loops will break mod_perl and produce compile warnings
No longer depends on: 304699
Depends on: 342238
We don't seem to have any dep loops that are breaking mod_perl, anymore, so I'm changing the summary.
Summary: Compile-time dependency loops will break mod_perl and produce compile warnings → Compile-time dependency loops can produce compile warnings
Also, this isn't actually blocking mod_perl work anymore.
No longer blocks: mod_perl
Running an altered version of 010dependencies.t (where require Bugzilla::Foo inside routines are not considered as part of dependency loops) shows no dependency loops anymore. The checking of 010dependencies.t will now prevent new loops from appearing. Marking this bug as fixed.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Bugzilla 3.0
You need to log in before you can comment on or make changes to this bug.