Header Files

[bitwise via Digitalmars-d]

On Sun, 10 May 2015 04:20:45 -0400, Marco Leise <Marco.Leise at gmx.de> wrote:
> 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.)

I'm not sure I understand what you're trying to say.

   Bit