Mercury Bugs - mercury
View Issue Details
0000536mercuryBugpublic2021-06-07 14:252021-06-25 16:06
Assigned To 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000536: --track-flags unreliable when invoked quickly
Descriptionmmc --make fails to rebuild modules when invoked multiple times quickly with different flags, despite using --track-flags. Presumably this has something to do with the poor resolution of timestamps returned by io.file_modification_time, so is a specific case of a more general problem with mmc --make.

set -x
rm -rf ./Mercury
mmc -m e --track-flags -s hlc.gc
#sleep 1
mmc -m e --track-flags -s hlc.gc -O3
#sleep 1
mmc -m e --track-flags -s hlc.gc -O4

+ rm -rf ./Mercury
+ mmc -m e --track-flags -s hlc.gc
Making Mercury/int3s/e.int3
Making Mercury/ints/
Making Mercury/cs/e.c
Making Mercury/os/e.o
Making e
+ mmc -m e --track-flags -s hlc.gc -O3
** Nothing to be done for `e'.
+ mmc -m e --track-flags -s hlc.gc -O4
** Nothing to be done for `e'.
TagsNo tags attached.
Attached Files

2021-06-25 15:22   
As starting point, I think we should decouple the notion of file timestamps from the other time related types in the standard library. (The latter are quite limited and ought to replaced, but that's a separate issue.)

I propose we introduce a new type io.file_time/0 (and whatever supporting operations are required) which maps on to whatever the highest resolution file time representation on the underlying platform is (.e.g java.nio.file.attribute.FileTime in Java, FILETIME structure on Windows etc.). We then add a new version of file_modification_time that returns that rather than a time_t.
2021-06-25 16:06   
That is a good idea.

Issue History
2021-06-07 14:25wangpNew Issue
2021-06-25 15:22juliensfNote Added: 0001148
2021-06-25 16:06zsNote Added: 0001149