On 10/12/09 12:36 AM, Steve Appling wrote:
Can someone explain how the up to date checking logic is supposed to
work. What exactly does it do with the task.inputs and task.output
settings?
Currently, it works like this:
1. if the task does not declare both inputs and outputs (possibly
empty), then assume the task is out-of-date.
2. if any of the output files were not built by the task, then the task
is out-of-date.
3. if any input file has been removed or added to the set of input files
since the task built the output files, then the task is out-of-date.
4. if any of the input files have changed since the task built the
output files, then the task is out-of-date.
5. the task is up-to-date.
We're missing a step between 4. and 5, which I haven't implementing yet
(but will soon):
4a. if any of the task inputs have changed since the task built the
output files, then the task is out-of-date.
This doesn't seem to work for the current Copy task. I don't
understand how the up to date code can know which input files are
important (match the CopySpec)
The task tells it. In the case of the Copy task, the getSource() method
is marked with @InputFiles.
and what files in the output a particular input file maps to.
The up-to-date code doesn't care about this. It's just interested in
whether any output file is out-of-date wrt any input file. The mapping
is the task's business.
This seems like knowledge that only the Copy task has. Because of
this, I'm not convinced that the Copy task should use the up to date
checking.
I think it's an excellent candidate for getting the up-to-date checking
right: there's a complex relationship between inputs and outputs, and
it's possible to do an incremental copy. We should try to get the
incremental build API to the point where it's a natural and comfortable
fit for the Copy task.
This will take a few steps. We're just at the first step, where we do
some coarse-grained checking to decide whether to skip or execute. For
this step, we just need to get Copy working correctly, and on average
faster than in 0.8 (which may mean slower for some executions and faster
for others). We can improve performance again, and the API, in later steps.
Currently, the Copy task seems broken and it is preventing me from
using the trunk version of Gradle. It will only do a copy the first
time. If I delete files in the target area (for example by doing a
clean), it will never copy them again if the source does not change.
Right now, the up-to-date checking cheats, and just checks whether the
output directory exists. It doesn't bother scanning to see what is
actually there. So, if you're deleting anything under the copy's
destination dir, but not the destination dir itself, then it won't
execute. I was hoping we could get away with this, because it's easier.
Looks like we won't be able to. I will fix this.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
