Don't get stuck on cyclic graphs where one edge has multiple outputs.
authorNico Weber <nicolasweber@gmx.de>
Wed, 1 Apr 2015 15:09:28 +0000 (08:09 -0700)
committerNico Weber <nicolasweber@gmx.de>
Wed, 1 Apr 2015 18:11:28 +0000 (11:11 -0700)
commit8e8cee81964996981473ed4ab004e61eb6600235
tree3d09f843d39188b7ee9990bcd031c5b44eb8de4a
parenta960fe2bf972467725626ae70422f44292be2834
Don't get stuck on cyclic graphs where one edge has multiple outputs.

Fixes #934. Plan::AddSubTarget() tracks in want_ if each edge has been
visited and visits every edge only once.  But Plan::CheckDependencyCycle()
worked on nodes however, so if a cycle was entered through an edge with
multiple outputs, ninja would fail to detect that cycle.

Move cycle detection to look for duplicate edges instead of nodes to fix
this.  The extra jump makes CheckDependencyCycle() a bit slower: for a
synthetic build file with 10000 serial build steps, `ninja -n` now takes
0.32s instead of 0.26s before on my laptop.  In practice, projects have
a dependency change length on the order of 50, so there shouldn't be a
noticeable slowdown in practice.  (If this does end up being a problem:
CheckDependencyCycle() currently does O(n) work and is called O(m) times
from AddSubTarget(), so I think cycle checking is O(n^2) in the build
depth.  So instead of worrying about constant overhead, we could use
a set<> instead of a stack<>.  But it doesn't seem to be a problem in
practice.)
src/build.cc
src/build_test.cc