D-lighted, I'm Sure

[H. S. Teoh]

On Fri, Jan 18, 2019 at 08:03:09PM +0000, Neia Neutuladh via Digitalmars-d-announce wrote:
> On Fri, 18 Jan 2019 11:43:58 -0800, H. S. Teoh wrote:
> > (1) it often builds unnecessarily -- `touch source.d` and it
> > rebuilds source.d even though the contents haven't changed; and
> 
> Timestamp-based change detection is simple and cheap. If your
> filesystem supports a revision id for each file, that might work
> better, but I haven't heard of such a thing.

Barring OS/filesystem support, there's recent OS features like inotify
that lets a build daemon listen for changes to files within a
subdirectory. Tup, for example, uses this to make build times
proportional to the size of the changeset rather than the size of the
entire workspace.  I consider this an essential feature of a modern
build system.

Timestamp-based change detection also does needless work even when there
*is* a change.  For example, edit source.c, change a comment, and make
will recompile it all the way down -- .o file, .so file or executable,
all dependent targets, etc.. Whereas a content-based change detection
(e.g. md5 checksum based) will stop at the .o step because the comment
did not cause the .o file to change, so further actions like linking
into the executable are superfluous and can be elided.  For small
projects the difference is negligible, but for large-scale projects this
can mean the difference between a few seconds -- usable for high
productivity code-compile-test cycle -- and half an hour: completely
breaks the productivity cycle.


> If you're only dealing with a small number of small files,
> content-based change detection might be a reasonable option.

Content-based change detection is essential IMO. It's onerous if you use
the old scan-the-entire-source-tree model of change detection; it's
actually quite practical if you use a modern inotify- (or equivalent)
based system.


> > (2) it often fails to build necessary targets -- if for whatever
> > reason your system clock is out-of-sync or whatever, and a newer
> > version of source.d has an earlier date than a previously-built
> > object.
> 
> I'm curious what you're doing that you often have clock sync errors.

Haha, that's just an old example from back in the bad ole days where NTP
syncing is rare, and everyone's PC is slightly off anywhere from seconds
to minutes (or if it's really badly-managed, hours, or maybe the wrong
timezone or whatever).  The problem is most manifest when networked
filesystems are involved.

These days, clock sync isn't really a problem anymore, generally
speaking, but there's still something else about make that makes it fail
to pick up changes.  I still regularly have to `make clean;make`
makefile-based projects just to get the lousy system to pick up the
changes.  I don't have that problem with more modern build systems.
Probably it's an issue of undetected dependencies.


T

-- 
I think Debian's doing something wrong, `apt-get install pesticide', doesn't seem to remove the bugs on my system! -- Mike Dresser