2024-06-24 07:10 AEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000536mercuryBugpublic2021-06-25 16:06
Assigned To 
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/e.int
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




juliensf (administrator)

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.


zs (developer)

That is a good idea.

-Issue History
Date Modified Username Field Change
2021-06-07 14:25 wangp New Issue
2021-06-25 15:22 juliensf Note Added: 0001148
2021-06-25 16:06 zs Note Added: 0001149
+Issue History