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

[via Digitalmars-d-bugs]

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

--- Comment #25 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Ketmar Dark from comment #24)
> (In reply to Steven Schveighoffer from comment #23)
> > Perhaps you are getting caught up in terminology. It's not a target the
> > build system is trying to generate.
> so it should *never* be (re)generated.

No, it will only be regenerated if different. But the build system isn't
involved in deciding when and where to build it. It just is concerned with the
.o, and the compiler builds the .di according to the build line (and these
funky rules).

> > But my point is, you don't tell it about building the .di file because the
> > build of the .di file is implicit in the rule for the .o.
> and build system doesn't even know that we are using implicitly regeneration
> for some files and that other files can depend of this unknown files. it's a
> very… strange way to using build system.

It's strange, but not the strangest I have seen. I won't say I think it's the
*best* way to do this, but the logic seems sound to me.

> 
> > But your project doesn't know how to build /usr/include/stdio.h, so why
> > should your project care about how some other project's .di file is made?
> i never need to (re)generate /usr/include/stdio.h, it's god-given.

An importing project does not know how to generate foreign .di files that it
depends on, so they are "god-given" also.

A project typically shouldn't depend on .di files inside itself, it has the .d
files, and you lose a lot of compiler nifty things, such as inlining and CTFE,
when you use .di files instead of .d

--