HA -- got a small repro testcase!
SConstruct: ----------------------
# This tests the too-many-rebuilds problem with SCons 2.3.1 (test)
# Run like this: scons all-defuns.obj
# Test setup (only runs once)
import os.path
if not os.path.exists('mkl'):
os.mkdir('mkl')
if not os.path.exists('test.c'):
open('test.c', 'w').write('int i;')
env=Environment()
env.SharedObject('all-defuns.obj', 'all-defuns.c')
results = env.Command('all-defuns.c', 'test.c', Copy('$TARGET', '$SOURCE'))
env.Depends(results, '#mkl')
--------------------------
Run that twice as "scons all-defuns.obj". The second time _shouldn't_
rebuild anything, but it will re-run the Copy command. SCons 2.3.0
correctly doesn't do anything the second time.
Note: just running "scons" with the above SConstruct won't show the bug;
there's an ordering dependency here, so just "scons" considers the targets
in a different order from "scons all-defuns.obj".
Dirk, I guess the ball's in your court! :-) Of course I want to keep
helping to solve it but at least you and interested others (hi Roberto!)
can give it a try.
I'll check in some of my new tracing code soon; it's been helpful to me so
far.
-- Gary
On Sun, Feb 2, 2014 at 3:49 PM, Gary Oberbrunner <[email protected]>wrote:
> Well, my smaller test case with just the "important" files works fine so
> far. It's probably just _too_ small. But in the meantime I have a more
> complete understanding of what's happening.
>
> I traced through the taskmaster as all this is happening.
>
> Note that in Taskmaster-speak, "considering" is prior to "evaluating".
>
> 1. Taskmaster considers all-defuns.obj (This is in find_next_ready_node)
> - That checks node status of all children (via target.children()
> because Node.children() defaults its scan arg to 1),
> including all-defuns.c and recursively the dir mkl
> - mkl is in state no_state (never examined), so
> it returns changed=True which means all-defuns.c "has changed" --
> and that gets cached as the node status for all-defuns.c (incorrectly).
> This happens during the get_all_children() call for all-defuns.obj.
> 2. Taskmaster evaluates mkl; it's actually fine and taskmaster marks
> it up-to-date (in taskmaster).
> 3. Taskmaster evaluates all-defuns.c;
> It checks node up-to-date states for children and itself
> and it itself is cached as out of date (see #1 above), so it
> decides to rebuild it.
>
> Some possibilities for fixing or workarounds:
>
> -> Maybe a node changed state that relies on a no_state child should
> not get cached? (This could be a little complicated to implement)
> -> maybe no_state shouldn't mean "changed"? But it probably can't
> mean "not changed" either... would have to add a third "don't know"
> state.
> -> maybe if we encounter a no_state object while checking parents it
> should try to set its state? (but that would require evaluating it, and
> it's too early for that)
>
> --
> Gary
>
--
Gary
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
