Other processes can modify mtimes too, which will stuff up autoclean

[GoogleCodeExporter]

With the atimes_runner(), if you are editing/creating some files in your
build directory while a build is taking place, you can modify the atimes of
files, including sources files (say main.c).

This isn't a big deal for building, because for building fabricate treats
outputs the same way as inputs (just checks whether they're there and
haven't changed), but for autoclean it's a problem, because you might end
up cleaning the source file you edited.

Till we come up with a better solution, Berwyn's suggestion is to mark
outputs as "output?" on the first build. If you autoclean now, it'll ask
you to confirm before it deletes files. Then on the second one if we get
the same outputs we can mark them as true outputs in the .deps file
("output"), and autoclean can delete them immediately, as it does now. This
would work because the chances of the same file being edited at the same
time during a build is almost zilch.

However, it'd be nice to come up with a better solution for atimes_runner
to autoclean safely, so if you have any ideas, let us know!

Original issue reported on code.google.com by benh...@gmail.com on 3 Aug 2009 at 2:18

[GoogleCodeExporter]

As per Michael Haggerty's speed tests, atimes_runner() is also *very* slow for 
larger
projects. See:

http://groups.google.com/group/fabricate-users/browse_thread/thread/64670b732d07
1b75

Original comment by benh...@gmail.com on 7 Aug 2009 at 2:08

[GoogleCodeExporter]

This really requires implementing system call tracing on windows (cf issue 3).  
This
can be done but isn't trivial because it involves nested tracking of 
subprocesses.
Check google for the EasyHooks library as a starting point.  We'd love to see 
someone
tackle this.

Original comment by berh...@gmail.com on 14 Oct 2009 at 4:50