Re: How to modify algorithm that determines weather a target needs rebuild

[Todd Showalter]

On Mon, Aug 9, 2010 at 9:19 AM, Paul Smith <address@hidden> wrote:
> On Mon, 2010-08-09 at 08:46 -0400, Todd Showalter wrote:

>>     I think you'll find if you try this that it mostly works but
>> breaks in strange ways every once in a while, and will be completely
>> unportable if you try to take it to another platform.  Think about
>> what happens, for instance, if you touch a couple of files and the
>> clock "ticks" in the middle of the operation.
>
> I think the plan was to use touch's -r option (or -t maybe) to set the
> timestamp to a specific time (that is, to the exact same time as the
> prereq file), rather than just setting the timestamp to "now".

    Which is fine, but the time you specify is almost certainly
quantized, and (especially if your files cross directory, filesystem
or machine boundaries) may be quantized to different values for
different files regardless of what touch specifies.  On some platforms
or filesystems it'll work as you expect, on others, not so much.  Or
it will work almost every time but go awry once in a blue moon.  In
some cases (some files on local storage, others on a network mount
from a different OS) I'd not be surprised if it never worked.

> That should be pretty safe across all kinds of filesystems, but Philip's
> question is the pertinent one here: how do you manage targets that have
> more than one prerequisite?

    Philip's question is very important with regards to how this will
(not) work with make; my point is that the fundamental idea of basing
things on filesystem timestamp equality is broken.  You have to treat
filesystem timestamps like floating point numbers; testing equality
without an epsilon fudge is the road to debugging hell. Worse, your
epsilon may well need to be large enough to render the system
untenable unless it's going to live on a single, well understood
filesystem.

                                                      Todd.

-- 
 Todd Showalter, President,
 Electron Jump Games, Inc.