I'll reply in detail, however, I want to formulate a considered reply.

Sounds good. Meanwhile, let me "think loud" when and why make can go wrong and how to fix that.

Make (in general, all variants) uses timestamps provided by the operating system and the file system to decide if a rule has to run or not. Rules run only once for each target during a single run of make, so make keeps an internal state, too. This state is obviously initially build from the timestamps.

Timestamps in the future may be caused by system clock manipulation. This happens, for example, when you damage your Slackware system, boot from the install CD/DVD, and chroot to your real system to rebuild the kernel using make. The Slackware installer manipulates the system clock (but not the hardware clock) to work around some problems with time zones, so you virtually travel in time. The same problem may happen when root changes the system time back manually while make runs. GNU make detects both and warns ("File '%s' has modification time %d s in the future"). It could, perhaps should, be more paranoid and abort instead, because it is likely that your build is incomplete.

Clock skew may happen when you use network filesystems (especially NFS) without tightly synchronising system clocks of client and server. The server sets the timestamps, using its system clock, but make on the client compares the timestamps using the client's system clock. That clock may have a very different idea of the current time, it may even jitter around the server's clock, so the freshly generated target may have a timestamp earlier than its source files. Again, it may also happen when root messes with the system clock. GNU make detects this and warns ("Clock skew detected"). Again, it could and perhaps should be more paranoid and abort, because again it is likely that your build is incomplete.

These two problems are the most common problems with make using timestamps, but there are other ways to create wrong timestamps.

FAT filesystems allow only a two-second-resolution of filestamps (you get only even values for seconds. So, your target may have the same timestamp as its source. But this should be no problem, you can get essentially the same problem because stat returns timestamps with only second resolution. Make only rebuilds when the target is older, i.e. timestamp of target is less than timestamp of source. But FAT stores local time, not universal time, so when you change the timezone, the FAT timestamps move back or forward in time.

No problem: The ntp deamon manipulates the system clock so it agrees with the reference clocks, perhaps even while you run make. If ntpd was implemented stupidly, the system clock would wildly jump around, especially if the system clock was off by several seconds or even minutes or hours. But ntpd is smart, it slows down or accelerates the system clock just a little bit at a time, so it smoothly aproaches the reference clocks' time. Generally, systems allow ntpd a single big adjustment of the system time during system boot to compensate cheap battery buffered real-time clocks that tend to run too slow or too fast.

Imagine a system without a battery-buffered realtime clock, like the old home computers or embedded systems. You boot the system, the system clock starts at some arbitary point in time (often with timer count = 0 or build date), and starts counting up, completely independant from any reference clock. No problem until you reboot. "Groundhog Day". Instant "timestamp in the future" problems. If the system has network access, start ntpd (or ntpdate) during boot. If the system is not networked (or just has no access to a reference clock), just make sure the system remembers the last count of its system clock across a reboot. This may be implemented as simply as touching a file once a second (or once a minute) as long as the system runs, and adjusting the system clock to the timestamp of that file during boot. Or, equally, by storing the timestamp in some kind of persistant storage (EEPROM, Flash, battery buffered RAM, ...) every minute or second, or at least in the shutdown script, and reading that value back during boot.

In summary, make sure that the system clock is synchronised with the reference clocks, and keeps counting upwards with no jumps. This will not only help make, but all other programs that rely on timestamps. Most times, the easiest solution is to start ntpd during boot, allowing a single big adjustment during startup of ntpd.

If you run on an isolated network, point to one arbitary machine and declare it holding the reference clock for that network. Serve time via NTP from that machine. Don't mess with its clock or timezone at all. If you have the resources, add a clock signal receiver to that machine (GPS or local radio like WWV, DCF77).

Alexander