Follow-up Comment #5, bug #19448 (project make):
What Christopher suggests might work, in principle, for Make jobs that are
performed sequentially. But what about parallel execution, where several
targets are remade asynchronously? Either we rely on the filesystem to
record time of creation for each target, or we will need to complicate the
communications between the sub-make's enormously to pass the extra data (and
even then I'm not sure it will work reliably, because with -j it is
theoretically possible that two targets were created at the same time
instance).
Anyway, given the fact that ``crappy filesystems'' are all but non-existent,
why bother inventing complicated mechanisms like that? It is much easier to
get Make to use the finest time resolution the filesystem can give us. Right
now, Make assumes that the st_mtime member of struct stat is the best we can
have, but that is not necessarily so on some systems. Maybe introducing
another abstraction that is independent of `stat' is a better way to handle
these problems.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?19448>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
