https://issues.dlang.org/show_bug.cgi?id=13517
--- Comment #13 from Andrei Alexandrescu <[email protected]> --- (In reply to Ketmar Dark from comment #12) > (In reply to Andrei Alexandrescu from comment #11) > > I've explained my reasons > no, you don't. you just keep saying "it will simplify everyone's life". My original argument: "Running dmd -H always generates a fresh .di file, even if an existing .di file exists and has identical content. This confuses build tools - such as make and derivatives - that rely on file timestamp to assess what needs to be rebuilt." Your conter-argument has been that that's the responsibility of the build tool. That's true, but it makes creating build tools for D more elaborate and more complicated than it should. My take is D should offer a simpler and better interface to classic build tools that consult timestamps and rely on the compiler to provide dependency information. I'll elaborate below. > and > when i'm saying that it will not (using your own style of argumentation, > actually), you accused me of bullying. With respect, that's exactly what happens. This is disproportionate response to a simple matter. > i don't want to talk on this issue anymore, it's meaningless. i don't see > any way of making discussion productive using such "no-op arguments". Let me elaborate how I see this would help building D projects. Currently (incremental builds, simple dependency management, no .di files), following the touch of xyz.d: 1. The deliverable depends on xyz.o and xyz.o depends on xyz.d. Therefore xyz.o is rebuilt. 2. The dependencies (previously saved with dmd -deps) list xyz.d as a dependence for all other modules that transitively import it. The timestamp of xyz.d has changed. Therefore the transitive closure of modules importing xyz must be rebuilt. 3. Finally deliverable(s) are linked etc. With .di files and without any special steps, the above doesn't change /because/ the .di files will be touched during the building of xyz.o. (There is a change in the sense that now modules depend on .di files, not .d files.) Now consider there's scripting around the build system that only touches xyz.di if it has new content. In that case, only a subset of changes to xyz.d will be reflected in xyz.di. So the process would go: 1. The deliverable depends on xyz.o and xyz.o depends on xyz.d. Therefore xyz.o is rebuilt. 2. The dependencies (previously saved with dmd -deps) list xyz.di as a dependence for all other modules that transitively import it. The timestamp of xyz.di may or may not have changed. In particular, changes to implementation of non-generic functions don't affect the interface. In that case there's no ripples. 3. Finally deliverable(s) are linked etc. This is going to go the same for all timestamp-based build systems so it's somewhat generic. The bit about touching the .di files conditionally is more D-specific. Now the question is where to place that code. Clearly the build tool could muster it. In my opinion it's easier to interface with generic build tools if the timestamps just work, as opposed to describing specifics on how these could be made to work. I'll also note that the story with .o files is quite different but may be worth looking at in the context of D. There are just few changes that don't affect .o file generation. The two that I can think of are comments and bodies of templates that aren't used within the same file. If we conclude these are somewhat frequent, conditional touching of the .o file may be interesting to do. --
