"Depended-on-by" not removed automatically
Status: Beta
Brought to you by:
worden
Menu
▾
▴
#109 "Depended-on-by" not removed automatically
With Xingpeng, we tried to make two different project directories depend on each other, which is apparently not supported. It's not clear why this should be an error condition if there are "do not copy" chains in the link, but I guess that's a different question.
Once this condition is reached, many different MP actions give errors, but Xingpeng managed to remove project B from project A's dependency list. Unfortunately, this did not resolve the error (project A continued to complain of circularity). Checking showed that project A's "depends-on" B line in project A's PD was still there. Removing it apparently resolved the problem.
Discussion
Anonymous
This is confusing. WW records dependencies by putting depends-on elements in the project description, so if that element was there, it can't be true that you successfully removed A's dependency on B. Maybe the wiki interface reported that it removed the dependency, but you didn't notice it was actually still on the list of dependencies?
Clearly you must always be able to remove a dependency, whether there's an error condition or not, so I accept this aspect of it as a bug to be fixed.
A second issue raised by this, and by a recent report from Jake, is why not allow circles of dependency. I definitely have to avoid infinite recursion when syncing the source files in dependency projects and their dependency projects. I addressed this problem by aborting when I detect a loop. But I could probably also address it just by skipping projects I've already seen, i.e. using a depth-first algorithm or whatever. It just never occurred to me that a circle would be anything but a mistake.
p.s. What does make do with dependency loops?
Don't know how I got so confused. I was talking about the "depended-on-by" tag, not the "depends-on" tag. I'm trying to change the name of the artifact to be correct.
Make has a heuristic to resolve dependency loops; it doesn't crash. But maybe it should; I don't think there's any use for dependency loops in make.
Dependency loops for projects could be useful, however: each project can see the others' files. I don't know if we want to allow it, for flexibility, or disallow it, to encourage structured design.
In fact, the initial description is even wronger than I thought!
XJ "removed" A from B's MP prereq list. This apparently removed the <depends-on a=""> from B's PD, but not the <depended-on-by b=""> from A's PD.</depended-on-by></depends-on>
That makes sense. It seems to me that WW probably started the remove-dependency operation by removing the depends-on, but encountered an error condition in the form of circular dependencies, and bailed without removing the corresponding depended-on-by. This is definitely a bug. It can be resolved in at least two ways:
catch the exception and make sure to finish the operation
don't raise the exception, because circular dependencies are actually okay.
Actually there's a third:
I don't actually think dependency loops need to be outlawed, so I'm probably going to do #2, which makes #1 moot, though it would be smart defensive programming to fix #1 anyway, in case of other exceptions being raised in WW's future.
The depended-on-by tag is not removed regardless of whether there was a loop or not.
OK, thanks. Please note that this is a minor issue, because depended-on-by isn't used for anything crucial. It's only used to expire wiki pages so that they're reparsed when a source file in an upstream project is changed. If there are outdated depended-on-by elements, they will cause a few pages to be reparsed unnecessarily. This should cost way less than a second apiece, because make doesn't redo unnecessary computations when the makefiles are correctly written: therefore the only meaningful cost is in rerunning the wikitext parser, not remaking project files, and that isn't very meaningful. I will fix the bugs (this report is for two bugs now), but please don't worry about these elements unduly.