Re: GNAT Modification_Time limitation

[briot.emmanuel@gmail.com]

> I am coding a kind of make application, that depends on file's time tag (thanks to Ada.Directories.Modification_Time), and on Ada.Calendar.Clock, both returning Ada.Calendar.Time.


Interesting. I am in the middle of a discussion with AdaCore about gprbuild, which fails to recompile when using an alternative body that happens to have the same time stamp (to the second). gprbuild sees that the modification time appears to be the same, and thus doesn't recompile.

Two points:
   - AdaCore mentioned they made progress recently on timestamp precision and it would likely fix the scenario. I think this is similar to what you reported, so it is likely your issue has been fixed now.

   - I am arguing with AdaCore that checking timestamps is not enough (might not even be useful at all), as Shark8 mentioned. The scenario I have is the following:

       Create a project with one scenario variable. Depending on that variable, chose src1 or src2 for source dirs. In each of these directories, have a file utils.adb with a different content. "touch" these two files so that they have the same timestamp. If you build your application once with one value of the variable, then rebuild with another value, gprbuild does nothing the second time.

I had a similar real case because git created two files with the same timestamp. And then it took me days to understand why some of my tests appeared to be linked with both versions of utils.adb, since I could see in the log file traces from both src1/utils.adb and src2/utils.adb.
Very very confusing.

So I would indeed recommend that you don't bother with timestamps, and only look at file contents (or use timestamp+file path at the very least, or perhaps inodes).

I am interested in hearing more why you want to code a new 'make-like' ?

Now trying to persuade AdaCore that gprbuild's behavior is incorrect...

Emmanuel