Mtime resolution when installing files
I stumbled upon this behavior when I embedded a cmake project in a meta-build system that uses GNU make. The logic of the meta-build system is simply a dependency from the binary cmake built to the installed file. To my surprise the installation step of the cmake project was invoked every time.
In a large system with many projects that can lead to a significant delay, so I investigated the cause. I found that cmake's file command will copy the binary and then, for some reason, set the mtime to a value that is slightly smaller than the one of the source file. It seems that cmake does not take into account the sub-second part.
Here is how you can test this:
$ mkdir /tmp/src
$ mkdir /tmp/install
$ cp /usr/bin/cmake /tmp/src
$ touch -m /tmp/src/cmake
$ LC_ALL=C stat /tmp/src/cmake | grep Modify
$ Modify: 2019-01-24 13:26:06.849911867 +0100
$ echo 'file(INSTALL DESTINATION "/tmp/install/" TYPE EXECUTABLE FILES "/tmp/src/cmake")' > /tmp/debug.cmake
$ cmake -P /tmp/debug.cmake
-- Installing: /tmp/install//cmake
$ LC_ALL=C stat /tmp/install/cmake | grep Modify
Modify: 2019-01-24 13:26:06.000000000 +0100
As you can see the mtime is rounded after installation. The filesystem of /tmp is tmpfs under Kernel version 4.19.15-300.fc29.x86_64. I could also reproduce this on ext4. cmake was cmake-3.12.1-1.fc29.x86_64 from the fedora repositories as well as version 3.12.3 built from scratch.