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

[Andrei Alexandrescu]

On 2/25/19 2:04 PM, Manu wrote:
> 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.

More like dog's ones, right? :o)

There are indeed arguments going either way. The point is a universe of 
tools can be built based on the compiler as a library, of which only a 
minority should be realistically integrated within the compiler itself.

That said, I'd take such work in either form!


Andrei