https://issues.dlang.org/show_bug.cgi?id=13517
--- Comment #11 from Andrei Alexandrescu <[email protected]> --- (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. --
