[M3devel] incremental build always rebuilds cm3, never produces the same thing -- what time is "now"?

[Jay]

In m3-sys\cm3, incremental build always rebuilds cm3, never produces the same thing.
 
I know exactly why. My modification to Olaf's timestamping (which I think he approved,
but perhaps didn't realize this outcome).
Because we generate a source file with the current time, and it always changes.
 
Is this ok with people?I know it has downsides, but it might be ok.
You know:
  1) incremental build should really never do anything, never writing anything, fast
      which is important -- never write, or be fast? both?
  2) You might want to compare two full builds and determine they are identical; the less of this sort of thing the better
If not, what do people suggest for a way to determine when to update the time?
The logic before I think was essentially never, unless you went and deleted a specific file.
Perhaps that is right, once it is discovered and publicized.
Perhaps another output directory is needed -- say <cvsroot>/<target> -- that upgrade and make-dist, perhaps, know to delete, and maybe realclean...of cm3? deletes? Hey, maybe just declare an output, with "..", in the m3makefile, so merely clean and realclean update the time, but incremental builds do not? This seems obviously the way to go right now, but still slightly debatable. Like, maybe an accurate timestamp is needed. Maybe if any other source or .lib changes, the timestamp should change -- so, like, m3_back/m3_link could regenerate the file, except that might be too late.
 
Should "now" be less granular than a second? That mitigates the problem but i think is not satisfactory.Should "now" be overridable on the command line or with an environment variable?
 
 - Jay
_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!!
http://biggestloser.msn.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080118/2a456998/attachment-0002.html>