Am Sat, 09 May 2015 10:01:25 -0400 schrieb bitwise <[email protected]>:
> ./main.d > ./pack/foo.d > ./pack/sub/bar.d > > dmd main.d pack/foo.d pack/sub/bar.d -ofTest -H > > This dumps all the *.di files into the output directory ignoring the > directory structure. > > Is there some rational for it being this way? > Wouldn't it be much more useful if directories were preserved? > > Bit I agree, D modules are hierarchical and sometimes share the same base name. Header files are very important to short circuit the transitive import chain. We've already seen it in Phobos. Many modules ends up pulling in most of Phobos, and those are library modules. Now imagine there was an operating system like Linux/GNU with all libraries written in D and no .di files: The program entry point in a project the size of OpenOffice would pull in so many imports that no super computer in the world could compile it given CTFE memory use: all of the project files, font library, math library, image library, entire GUI toolkit, Java binding, accessibility library, RPC library, configuration library, OpenGL, audio, GhostScript and PDF, Python, XML, MS Office file type readers, ICU, SSL, Phobos, X11 or similar, color management, printing, zip, databases, ... We often shun .di files, thinking of them as C++ relics, but the big difference is that we don't write them. The compiler generates them and they are still a key to a successful eco-system with huge projects, just the way they are in C/C++. One thing I'm missing is a way to tell the compiler or a build tool which symbols or modules are part of the library API. There is no sense in generating an "internal.di" and similar files that are never supposed to be used by the outside. (They'd also be listed unnecessarily in import auto-completions of Mono-D and similar IDEs.) -- Marco
