Re: GNAT corrupted builds with below second changes

["Randy Brukardt" <randy@rrsoftware.com>]

"Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message 
news:p8atvh$74r$1@dont-email.me...
> Hi,
>
> I'm doing some automated testing that involves very fast file generation 
> and recompilation. Platform is linux, GPL 2017 or FSF 7.2. I've observed 
> that gprbuild seems to not detect that a file is changed if less than a 
> second has elapsed. I will guess here that the timestamp being used has 
> second precision. This leads to supposedly up-to-date builds that aren't, 
> among other funny effects.
>
> I faintly remember having read about this somewhere, but I'm unable to 
> find anything related in web searches. Anyone has experienced this?

Not with GNAT, but we used to have such problems with Janus/Ada programs. I 
believe it caused certain ACATS tests to intermittently fail. I think I 
"fixed" that by introducing a delay into the compiler in certain 
circumstances (the delay being barely noticable to humans, but long enough 
to ensure that the time stamps are unique). [I don't remember for sure 
whether I fixed the problem, but since I don't remember it happening in the 
last 5 years, it seems likely that I did something to prevent it.] A better 
fix would have been to stop using time for such checks (compiles having 
gotten fast enough to make identical timestamps probable, and more so with 
every new generation of computers), but that would have required a lot of 
compiler and library change. (Definitely not the quick fix I was looking for 
at the time.)

It wouldn't surprise me if GNAT ran into similar issues -- the file 
timestamps on Windows (which is what we were/are using) have a 2 second 
granularity.

                                       Randy.