| Re: [hatari-devel] Strange timestamp issue |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
On 27.7.2024 0.14, Uwe Seimet wrote:
When compiling with Pure C I have an issue with the timestamps of the .C and
.O files. When I save a .C file in the Pure C editor it will automatically be
recompiled when I trigger the Pure C make process. After the new .O file has
been created, when I trigger the make process again, Pure C again compiles
this file, even though nothing should be done anymore. With a real Atari
there is no such problem, i.e. Pure C correctly detects that the .O file is
newer than then .C file.
What are your time options for Hatari:
-------------------------------------------
$ grep -e Rtc -e HostTime ~/.config/hatari/hatari.cfg
bGemdosHostTime = TRUE
nRtcYear = 0
-------------------------------------------
?
If one uses host timing for files, it's better to use setup (TT/Falcon)
where emulation (RTC) clock is taken from the host, and RTC clock value
offset is _not_ used (=0), and one does not use fast-forwarding.
That's best option when one creates files both on host and emulation
side. If one does everything under emulation, it would be better to
disable GEMDOS HD host time use.
FYI: changing these can be done with:
-------------------------------------------
$ hatari --help | grep -e gemdos-time -e rtc
--gemdos-time <x> Which timestamps to use for GEMDOS files (atari/host)
--rtc-year <x> Set initial year for RTC (0, 1980 <= x < 2080)
-------------------------------------------
When looking at the timestamps in bash this is what I get right after saving
the .C file in Pure C:
-rw-rw-r-- 1 us users 76956 Jul 26 2024 PART.C
-rw-rw-r-- 1 us users 53080 Jul 26 23:00 PART.O
Does 'stat' give proper timestamp when 'ls' does not?
There is a date but no timestamp for PART.C. After some time (about a
minute) the timestamp appears without any further action on my side:
-rw-rw-r-- 1 us users 76956 Jul 26 23:02 PART.C
-rw-rw-r-- 1 us users 53080 Jul 26 23:00 PART.O
Timestamp difference is interesting as Atari file time granularity is 2s...
Hatari does host file system actions only as responses to GEMDOS API
calls. Therefore I don't see how timestamp changing that much afterwards
could be due to Hatari, unless the Atari application *is* actually doing
something for the files at both of those times...
(Please check from GEMDOS trace what actually happens.)
As far as I can tell, as long as the shell does not display a timestamp Pure
C thinks that the .C file is newer than the corresponding object file and
recompiles it.
Note that the "lazytime" option is active for my filesystems, but I don't
think this is related, because in Linux this has not caused me any troubles
for ages, e.g. when using make or cmake with Linux.
> Any idea what's happening here, and why only Hatari seems to be affected?
'ls' not showing timestamp immediately could be due to lazytime.
Pure-C issue is likely related to Hatari options I mentioned.
- Eero