comp.lang.ada
 help / color / mirror / Atom feed
From: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Subject: Re: GNAT corrupted builds with below second changes
Date: Thu, 15 Mar 2018 14:24:10 +0100
Date: 2018-03-15T14:24:10+01:00	[thread overview]
Message-ID: <p8ds5q$tdq$1@dont-email.me> (raw)
In-Reply-To: <p8c9ad$emj$1@franka.jacob-sparre.dk>

On 14/03/18 23:56, Randy Brukardt wrote:
> "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 did this initially but it mounted up, so I'm now manually deleting 
.o/.ali files for a few critical files only.

> [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.

The funny thing is I'm almost sure of having read somewhere that this 
had been addressed in gnat specifically, but I can't locate it.

Thanks,
Álex.


  reply	other threads:[~2018-03-15 13:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14 10:36 GNAT corrupted builds with below second changes Alejandro R. Mosteo
2018-03-14 22:56 ` Randy Brukardt
2018-03-15 13:24   ` Alejandro R. Mosteo [this message]
2018-04-22  5:53   ` David Thompson
2018-03-15 18:52 ` Shark8
2018-03-15 19:59   ` Bojan Bozovic
2018-03-16  3:27     ` Shark8
2018-03-16  4:29       ` Bojan Bozovic
2018-03-16  5:37       ` J-P. Rosen
2018-03-18  6:09         ` Robert I. Eachus
2018-03-16  8:42       ` Dmitry A. Kazakov
2018-03-18  5:21     ` Robert I. Eachus
2018-03-15 21:03   ` Jeffrey R. Carter
2018-03-16  2:51     ` Shark8
2018-04-22  7:31 ` Simon Wright
2018-04-22 14:04   ` J-P. Rosen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox