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

[Rubn]

On Monday, 25 February 2019 at 19:28:54 UTC, H. S. Teoh wrote:
> 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

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. Add in different different operating 
systems to that. Each have different requirements and how do you 
not make assumptions? You have to implement something in some 
way, you can't just not implement it. Doing so you weigh the 
benefits and drawbacks of certain implementations. That means a 
build system may not be suitable for all circumstances and it is 
impossible for it to. If you are building something simple it is 
very easy to say that build-systems are over complicated. If you 
don't have to worry about not rebuilding files that don't have 
to, then it becomes extremely simple, my <50 line build script is 
all I need but then that becomes more complicated if I don't want 
to rebuild files that don't need to. That is especially bad for 
something like D where you can import any where and with mixins 
that can import as well using from!"std.stdio".

It's easy to say build-systems are overly complicated until you 
actually work on a big project.