Gary,
Can you please point me to the testcase you are investigating? I would like to test it with the scons code Im running ( dirk patch + some in house changes): my developers that are running the experimental code did not report problems so far, so I see a few options: 1) our company work does not include a case like your one 2) my people did not realized the defect 3) our in house changes ( really few things) may have fixed the problem.. in such a case I would be happy to provide them. regards, roberto _____ From: [email protected] [mailto:[email protected]] On Behalf Of Gary Oberbrunner Sent: Tuesday, January 28, 2014 23:57 To: Dirk Baechle; SCons developer list Subject: Re: [Scons-dev] please try latest default branch 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? On Sun, Jan 26, 2014 at 11:15 AM, Gary Oberbrunner <[email protected]> wrote: I'm continuing to track this down. No solid results so far (but I'm adding lots of tracing code). I have a generated source file, all-defuns.c, that depends (using Depends) on a dir (mkl), and it seems like with the new code while the taskmaster is checking all-defuns.obj it checks all-defuns.c, which calls Dir.changed() on the dir, which just checks the node.state -- and the state is no_state, i.e. it hasn't been evaluated yet, which changed() interprets as being changed, so it decides to regenerate the source file all-defuns.c. Later, when the taskmaster gets to checking the mkl dir, it finds all of its children are up to date and marks it up to date, but it's too late by then. I suspect (?) something in the taskmaster updates but will have to keep poking at it. On Tue, Jan 14, 2014 at 1:39 PM, Dirk Bächle <[email protected]> wrote: > On 14.01.2014 14:44, Gary Oberbrunner wrote: >> >> OK, I'll try that. I guess the approach should be to set a new >> (temporary) flag in the node when its executor is released, and then print a >> stack trace if any node with that flag set gets its changed() method called? >> > This flag already exists and it's called "self.released_target_info" (check > the end of the relase_target_info() method). > Then you want to use the KeyError exception path in File.changed() like > this: > > if node is None: > > try: > return self._memo['changed'] > except KeyError: > if self.released_target_info: > # We have no executor anymore, but the cached "changed" > # value doesn't exist either -> print stacktrace! > > > Dirk > > > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev -- Gary -- Gary
_______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
