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

[Manu]

On Mon, Feb 25, 2019 at 10:10 AM Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 2/25/19 5:20 AM, Jacob Carlborg wrote:
> > On 2019-02-25 02:04, Manu wrote:
> >
> >> Why wouldn't you do it in the same pass as the .di output?
> >
> > * Separation of concerns

Are we planning to remove .di output?

> > * Simplifying the compiler ("simplifying" is not the correct
> > description, rather avoid making the compiler more complex)

It seems theoretically very simple to me; whatever the .di code looks
like, I can imagine a filter for isExternCorCPP() on candidate nodes
when walking the AST. Seems like a pretty simple tweak of the existing
code... but I haven't looked at it.
I suspect 1 line in the AST walk code, and 99% of the job, a big ugly
block that emits a C++ declaration instead of the D declaration?

> 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?
At best, it would take me hours or days of implementing that
comprehensive solution, it might not be possible in all build
environments (XCode is a disaster), and I will never spare that time.
Give me dtoh, you give me problems, not solutions.

Certainly it *could* be a separate tool, but your argument that it's
more enabling as a separate tool is the opposite of the truth. At
best, it'll just waste more precious CI time and complicate our build.