ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: [Submit] Rounding error with dependency checking in
Date Tue, 27 Nov 2001 19:59:46 GMT
At 07:56 PM 11/27/2001 +1100, Peter Donald wrote:

>We also can't apply the check in sourcefile scanner because in some cases the
>modification time will be less than a second. In a few cases I have a build
>process that will modify or generate source files that should be recompiled
>in same sweep but would not have a modification time 1000ms in the past.

I was afraid someone would feel that way.

Of course, you realize this behaviour is not portable. If you are checking 
dependencies between files that may have changes less than a second apart, 
any platform that does not support millisecond granularity will silently 
hose whatever you are doing. Still, I can see that if you are resticting 
yourself to a platform where it does work (and are not sharing your build 
files without a large caveat), the fuzziness I introduced would be a bad thing.

>I think the best idea for you would be to write a custom task.

But then anyone else that faces granularity issues will have to do the same 
debugging I did, discover the problem, and implement their own custom task. 
And if they don't realize there is a problem to begin with, Ant will give 
completely incorrect results without any notice. This type of rounding 
error will often show up in subtle ways that aren't easily caught.

How about this: adding an attribute to <mapper> that allows you to set the 
accuracy of the dependency time comparison. By default it would be 0, but 
you could adjust it in your build file if necessary. Someone would still 
need to be aware of the time issue, of course, but there would be a simple 
build file change available to fix it.

The only ugliness here is that <mapper> is used in multiple ways, both to 
rework filenames (most of the time) and to filter out files in filesets 
both through dependencies and failure to match a regular expression (some 
of the time). If I can get agreement that adding the attribute is a benign 
change, are there thoughts on splitting this functionality apart or should 
I embrace this duality and put the attribute in <mapper>?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message