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

[via Digitalmars-d-bugs]

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

--- Comment #23 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Andrei Alexandrescu from comment #21)

> 
> Wouldn't that be easily achieved by "rm -rf generated/*.di" at the beginning
> of that separate step?

Sure, but "easily achieved" is not "easily explained" or "easily justified"

It is very counterintuitive to have a tool that is resolving dependencies to
require an extra step to update the date of file. Especially one that does not
act that way for any other generated files.

I will note, this will break a LOT of existing projects. Including druntime.

(In reply to Ketmar Dark from comment #20)
> (In reply to Steven Schveighoffer from comment #17)
> so it's not a "side effect", .di file has to be explicitly asked.

Perhaps you are getting caught up in terminology. It's not a target the build
system is trying to generate. Whatever term you want to use for that, use that.

> no, it's not a "side effect". and build tool doesn't know how to build .o
> from .d too. one must provide the rule which builds .o from .d. one must
> provide the rule which builds .di from .d. simple and easy.

It knows how to build the .o because we tell it. E.g.:

%.o : %.d
      dmd -c -H %.d

(please note, not a makefile expert, so the above may not be valid make syntax,
but I hope you get the idea)

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.

> 
> > But as I said, you would need to ensure the project that builds the .di file
> > cannot depend on the .di file, because it doesn't know how to build them, it
> > just does so as a side effect.
> if project uses generated files that eventually needs regeneration and it's
> build system doesn't know about that files, this project's build scripts are
> foobared. that is exactly the mess that will lead to complete disaster
> sooner or later.

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?

It requires some manual ordering. For instance, you can't just treat all
project files as individuals, you have to build all files for project a first
if project b depends on a.

One thing that would make this scheme fail is if one removes the .di file and
expects it to regenerate. But I think this is a caveat of an uncommon build
system, you just have to live with that.

I will say, I think the enhancement is unusual and counterintuitive. It may be
best to enable this mechanism with a special flag. Maybe like -H+

--