On 28.01.2014 23:57, Gary Oberbrunner wrote:
More results, no fix yet.
The generated file all-defuns.c I mentioned before is definitely part
of the problem. I back-ported the tracing code I wrote to just before
Dirk's memory optimization. In that version, near the beginning of
the build phase something calls node.is_up_to_date() on all-defuns.c
and it says it has changed, due to depending on a dir "mkl" which is
in no_state (i.e. hasn't been evaluated yet). In Dirk's version, this
result gets cached, which seems sensible. But in the old version,
when the taskmaster considers that all-defuns.c node, and calls
is_up_to_date(), now it correctly returns True, because by now the mkl
dir has been evaluated and it's in up-to-date state. So it's
definitely the caching that's causing the trouble, but I don't
understand why is_up_to_date should return different values at
different times -- especially go from false to true before anything's
been built. Perhaps there's another bug in the code which Dirk's
patch exposes?
I would think is_up_to_date() should never assume that being
unprocessed (i.e. no_state) means not up-to-date; I'd think it should
have scanned the no_state node before its dependents. Anyone have any
clues?
When I implemented my changes, I saw that in the old version the
changed() (or connected methods) could be actually called after a file
was built. And since there was nothing cached, this could lead to
creating additional build infos in the same step. So there was a danger
of having a build info hash signature in the .sconsign, that would not
actually describe how the target was built (more like, how would it be
built next time).
Maybe your build DAG relied on this fact so far? By the way, are you
building with "-j" or is it failing single-core too? Do you think it's
possible to extract an isolated test case from this, now that we know
more about what seems to happen?
Regarding the is_up_to_date() method, we're pretty much on the same page.
Dirk
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
