Change 3968
Fix //guest/matt_armstrong/jam/bug/1/... and
//guest/matt_armstrong/jam/bug/2/... in one go.
jam2.5rc3 attempts to turn INCLUDES into DEPENDS by turning every
INCLUDES into an implicit node in the dependency graph. The
problem with this approach is that make.c and make1.c algorithms
work only with acyclic graphs, and INCLUDES relationships are
often cyclic.
This branch backs out //public/jam/src/... changes 2614 and 3057
and merges in //guest/matt_armstrong/jam/fix/includes/... changes
2573, 2574 and 2575.
The end result is that make.c now copies a target's INCLUDES to
its DEPENDS list as it walks through the graph. The end result is
that at the end of make.c, every target's DEPENDS list includes
all its direct dependencies *and* all of the implicit dependencies
that INCLUDES creates. This creates more nodes, but is immune to
cycles in the INCLUDES chain.
An alternative approach would be to change every use of t->depends
to use a smart iterator. The iterator would generate a temporary
list containing all of t->depends and all of associated INCLUDES.
This list would be iterated over and disposed. I didn't take this
approach because it was more complex, and I rather like the -dd
debug output my patch generates (i.e. the "implicit" lines for
DEPENDS and INCLUDES relationships that are implicitly created via
INCLUDES).
//guest/matt_armstrong/jam/bug/2/... in one go.
jam2.5rc3 attempts to turn INCLUDES into DEPENDS by turning every
INCLUDES into an implicit node in the dependency graph. The
problem with this approach is that make.c and make1.c algorithms
work only with acyclic graphs, and INCLUDES relationships are
often cyclic.
This branch backs out //public/jam/src/... changes 2614 and 3057
and merges in //guest/matt_armstrong/jam/fix/includes/... changes
2573, 2574 and 2575.
The end result is that make.c now copies a target's INCLUDES to
its DEPENDS list as it walks through the graph. The end result is
that at the end of make.c, every target's DEPENDS list includes
all its direct dependencies *and* all of the implicit dependencies
that INCLUDES creates. This creates more nodes, but is immune to
cycles in the INCLUDES chain.
An alternative approach would be to change every use of t->depends
to use a smart iterator. The iterator would generate a temporary
list containing all of t->depends and all of associated INCLUDES.
This list would be iterated over and disposed. I didn't take this
approach because it was more complex, and I rather like the -dd
debug output my patch generates (i.e. the "implicit" lines for
DEPENDS and INCLUDES relationships that are implicitly created via
INCLUDES).