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

[H. S. Teoh]

On Mon, Feb 25, 2019 at 11:04:56AM -0800, Manu via Digitalmars-d wrote:
> On Mon, Feb 25, 2019 at 10:10 AM Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
[...]
> > Indeed so. There's also the network effect of tooling. Integrating
> > within the compiler would be like the proverbial "giving someone a
> > fish", whereas framing it as a tool that can be the first inspiring
> > many others is akin to "teaching fishing".
> 
> That sounds nice, but it's bollocks though; give me dtoh, i'm about
> 95% less likely to use it. It's easy to add a flag to the command line
> of our hyper-complex build, but reworking custom tooling into it, not
> so much.
> I'm not a build engineer, and I have no idea how I'd wire a second
> pass to each source compile if I wanted to. Tell me how to wire that
> into VS? How do I wite that into XCode? How do I express that in the
> scripts that emit those project formats, and also makefiles and ninja?
> How do I express that the outputs (which are .h files) are correctly
> expressed as inputs of dependent .cpp compile steps?
[...]

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


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.