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

[via Digitalmars-d-bugs]

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

--- Comment #11 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Ketmar Dark from comment #10)
> (In reply to Andrei Alexandrescu from comment #9)
> > Just stating it won't make it true.
> same for you. all this conversation boils down to "i believe that this will
> help." "and i don't." "and i believe." "and i don't."

I've explained my reasons: it's the right place to put this kind of logic
because it simplifies the use of .di files for everyone.

> what build tools do you mean? is there any sane build tool that can't cope
> with (re)generating ".di" from ".d"? why compiler should do the work for
> which build tools were built?

There is indeed some complication. make must be invoked two times in order to
first generate and then use the dependencies. This is because make has separate
stages for reading dependencies and building stuff; at work we used to drive
two calls to make, but more recently we have a build system (actually two) that
know how to maintain dependencies dynamically.

It is customary for today's advanced languages to provide dependency
information for build tools, and D is no exception. Maintaining dependencies
manually by tools that are poorly suited to grok language semantics does not
scale well.

> it's compiler work to (re)generate everything we asked it to. and it's build
> tool's work to minimize compiler invocations by doing various checks. good
> build tool is perfectly able to notice that we need both new ".di" and new
> ".o" files and do it with one exec().

This view is rather simplistic. The "various checks" depend on how the language
manages dependencies and need to be helped by language-specific tools, of which
the most obvious is the compiler itself.

> also imagine that i'm doing "force rebuilding". we'll need new command line
> flag that which tells dmd to regenerate .di file even if it's source .d file
> was not changed. sure we can workaround that by teaching build tool to call
> 'touch' or something, but for what reason?

A force rebuild would start by deleting generated .di files.

> either we have full-blown build tool in the compiler itself or we don't try
> to teach compiler some tricks which build tool should do and then start
> fighting with compiler to stop it tricking.

This is simple correct generated file management: what doesn't change doesn't
get touched. I don't understand the agitation around this.

> i'm on for the concept of "cached ASTs" (something like delphi's .dcu files)
> and teaching dmd to rebuild all changed modules and updating cached ASTs.
> this will greatly imporoves compilation speed (no need to do lexing, parsing
> and semantic analyzis again and again) and will become a nice and simple
> build system. but this is a very complex change and it's completely
> independent of ones you proposing.

I encourage you to submit that as a separate enhancement request for that. But
please stop bullying this into the ground. I don't have the time to defend it
and I have no interest in "winning" the argument consider you've won; I do have
skin in the game and need to see this through. On the other hand it's
relatively easy for you to naysay this by brute force. Clearly we could talk at
great lengths about the relative responsibilities of compilers and external
build tools, seeing as it's a matter in which reasonable people do disagree.
Also scripting around the language is a definite possibility. But a stalemate
here leads to the net result that nothing gets done and there's no progress. So
please don't make this all into a net negative. Thanks.

--