check_clock_skew: how dangerous is it to disable this check? and can we make it better/different

[virtuald]

In my workplace we have a bunch of internal development networks that each have their own NFS server that home directories and shared directories are on, and for a variety of reasons (that are very much out of my control) none of them have their clocks synced, and fixing that would be a really challenging non-technical problem. When using make it often complains about clock sync, but it builds. With meson, it fails because the clocks are out of sync. For now, I just have a forked version of meson and I have that commented out, but I wonder if we can do better?

I'd love to do some experimentation to see if we can make meson be correct even in the face of clock skew. #6435 introduced this change, and claimed that sometimes meson would go into eternal reconfiguration loops, without giving an example of how to trigger that case. @jpakkane do you recall how you ran into this?

[eli-schwartz]

One possible problem:

• this is the list of files which are considered to be regenerate dependencies for build.ninja -- if they have timestamps newer than build.ninja (always roughly the current time), then ninja should try to rebuild the build.ninja file, successfully do so, but get nowhere since it is still not new "enough" and thus try to rebuild it again.

  For a bare Makefile, you can get the problem under control: all output files, even if they are produced as very old compared to the input files, have to exist in some manner, so they will probably get built regardless. Incremental rebuilds will probably be totally broken.

  For a Makefile generated via a configure script, e.g. autotools, I would expect things to be a bit more problematic -- if Makefile.in is much newer than the current time, and Makefile is considered "out of date" compared to it, then running make is probably going to run ./configure again, much like meson. But whether the problem actually manifests would depend on just how much the skew is.