Make DMD emit C++ .h files same as .di files

[Manu]

On Mon, Feb 25, 2019 at 2:55 PM H. S. Teoh via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Mon, Feb 25, 2019 at 10:14:18PM +0000, Rubn via Digitalmars-d wrote:
> > On Monday, 25 February 2019 at 19:28:54 UTC, H. S. Teoh wrote:
> [...]
> > > <off-topic rant>
> > > This is a perfect example of what has gone completely wrong in the world
> > > of build systems. Too many assumptions and poor designs over an
> > > extremely simple and straightforward dependency graph walk algorithm,
> > > that turn something that ought to be trivial to implement into a
> > > gargantuan task that requires a dedicated job title like "build
> > > engineer".  It's completely insane, yet people accept it as a fact of
> > > life. It boggles the mind.
> > > </off-topic rant>
> [...]
> > I don't think it is as simple as you make it seem. Especially when you
> > need to start adding components that need to be build that isn't
> > source code.
>
> It's very simple. The build description is essentially a DAG whose nodes
> represent files (well, any product, really, but let's say files for a
> concrete example), and whose edges represent commands that transform
> input files into output files. All the build system has to do is to do a
> topological walk of this DAG, and execute the commands associated with
> each edge to derive the output from the input.

Problem #1:
You don't know the edges of the DAG until AFTER you run the compiler
(ie, discovering imports/#includes, etc from the source code)
You also want to run the build with all 64 cores in your machine.

File B's build depends on file A's build output, but it can't know
that until after it attempts (and fails) to build B...

How do you resolve this tension?
There's no 'simple' solution to this problem that I'm aware of. You
start to address this with higher-level structure, and that is not a
'simple DAG' anymore.

Now... whatever solution you concluded; express that in make, ninja,
MSBuild, .xcodeproj...