Header Files

[Marco Leise via Digitalmars-d]

Am Sat, 09 May 2015 10:01:25 -0400
schrieb bitwise <bitwise.pvt at gmail.com>:

> ./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