> From: Jeffrey Walton <noloa...@gmail.com> > Date: Wed, 19 Feb 2025 09:04:27 -0500 > Cc: Eldred HABERT <m...@eldred.fr>, bug-make@gnu.org > > On Wed, Feb 19, 2025 at 7:41 AM Eli Zaretskii <e...@gnu.org> wrote: > > > > It is not that simple. GNU Make uses 'stat' to retrieve the time > > stamp of files, and the Windows implementation of 'stat' reports times > > without hi-res data. So to define FILE_TIMESTAMP_HI_RES in the native > > Windows port of GNU Make, someone will need to produce a > > reimplementation of 'stat' that returns higher-resolution time stamp. > > > > Patches are welcome. > > > > (The MSYS2 port uses the Cygwin runtime library, whose 'stat' does > > provide hi-res times. But the native port cannot use the Cygwin > > runtime, it must use the native runtime or the Win32 APIs.) > > Another sharp edge is, the hi-res timer on Windows may appear to move > backwards in time as queries are made on different cores. Also see > <https://stackoverflow.com/q/44020619>.
Right. But that's not the hi-res time information I had in mind. I meant to use the 0.1 usec resolution of file times, and the corresponding APIs that return system time with that resolution. Those do not use the hi-res time described in the above SO article, and they don't move back, AFAIK.
