[Issue 13517] Only touch .di generated file if changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13517

--- Comment #13 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Ketmar Dark from comment #12)
> (In reply to Andrei Alexandrescu from comment #11)
> > I've explained my reasons
> no, you don't. you just keep saying "it will simplify everyone's life".

My original argument: "Running dmd -H always generates a fresh .di file, even
if an existing .di file exists and has identical content. This confuses build
tools - such as make and derivatives - that rely on file timestamp to assess
what needs to be rebuilt." Your conter-argument has been that that's the
responsibility of the build tool. That's true, but it makes creating build
tools for D more elaborate and more complicated than it should. My take is D
should offer a simpler and better interface to classic build tools that consult
timestamps and rely on the compiler to provide dependency information. I'll
elaborate below.

> and
> when i'm saying that it will not (using your own style of argumentation,
> actually), you accused me of bullying.

With respect, that's exactly what happens. This is disproportionate response to
a simple matter.

> i don't want to talk on this issue anymore, it's meaningless. i don't see
> any way of making discussion productive using such "no-op arguments".

Let me elaborate how I see this would help building D projects.

Currently (incremental builds, simple dependency management, no .di files),
following the touch of xyz.d:

1. The deliverable depends on xyz.o and xyz.o depends on xyz.d. Therefore xyz.o
is rebuilt.

2. The dependencies (previously saved with dmd -deps) list xyz.d as a
dependence for all other modules that transitively import it. The timestamp of
xyz.d has changed. Therefore the transitive closure of modules importing xyz
must be rebuilt.

3. Finally deliverable(s) are linked etc.

With .di files and without any special steps, the above doesn't change
/because/ the .di files will be touched during the building of xyz.o. (There is
a change in the sense that now modules depend on .di files, not .d files.)

Now consider there's scripting around the build system that only touches xyz.di
if it has new content. In that case, only a subset of changes to xyz.d will be
reflected in xyz.di. So the process would go:

1. The deliverable depends on xyz.o and xyz.o depends on xyz.d. Therefore xyz.o
is rebuilt.

2. The dependencies (previously saved with dmd -deps) list xyz.di as a
dependence for all other modules that transitively import it. The timestamp of
xyz.di may or may not have changed. In particular, changes to implementation of
non-generic functions don't affect the interface. In that case there's no
ripples.

3. Finally deliverable(s) are linked etc.

This is going to go the same for all timestamp-based build systems so it's
somewhat generic. The bit about touching the .di files conditionally is more
D-specific. Now the question is where to place that code. Clearly the build
tool could muster it. In my opinion it's easier to interface with generic build
tools if the timestamps just work, as opposed to describing specifics on how
these could be made to work.

I'll also note that the story with .o files is quite different but may be worth
looking at in the context of D. There are just few changes that don't affect .o
file generation. The two that I can think of are comments and bodies of
templates that aren't used within the same file. If we conclude these are
somewhat frequent, conditional touching of the .o file may be interesting to
do.

--