https://issues.dlang.org/show_bug.cgi?id=13517
--- Comment #10 from Ketmar Dark <[email protected]> --- (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." 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? 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(). 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? 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. 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. --
