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

[H. S. Teoh]

On Tue, Feb 26, 2019 at 01:33:50AM +0000, Rubn via Digitalmars-d wrote:
> On Monday, 25 February 2019 at 22:55:18 UTC, H. S. Teoh wrote:
[...]
> What build systems are you talking about here? I mean I can search for
> programs that do certain things and I'll most definitely find more
> subpar ones than any spectacular ones. Especially if they are free. So
> we are on the same page on which build systems you are referring to.

SCons is free, and does all of what I described and more.  It's not
perfect, of course.  But it's miles better than, say, make -- for its
unreliability and the tendency for makefiles to become unreadably
complex and unmaintainable. Or dub, for forcing you to work a certain
way and unable to express things like multi-stage builds or
non-compilation tasks.


[...]
> > - Compile a subset of source files into a utility;
> > 
> > - Run said utility to transform certain input data files into source
> >   code;
> > 
> > - Compile the generated source code into executables;
> > 
> > - Run said executables on other data files to transform the data into
> >   PovRay scene files;
> > 
> > - Run PovRay to produce images;
> > 
> > - Run post-processing utilities on said images to crop / reborder them;
> > 
> > - Run another utility to convert these images into animations;
> > 
> > - Install these animations into a target directory.
[...]
> Yes doing all those things isn't all that difficult, it really is just
> a matter of calling a different program to generate the file.

And yet the above build is not expressible in dub.


> The difficulty of build systems comes in when you have an extremely
> large project that takes a long time to build.

The above steps are part of a project I have whose full build takes
about 5-6 hours.  But while working on it, the build turnaround time is
about 10-15 seconds (and that's only because SCons didn't get one thing
right: that build time should be proportional to changeset size, rather
than the size of the entire workspace -- otherwise it would be more like
3-4 seconds).  *That's* what I call a sane build system.


[...]
> It really depends on what you are building. Working on DMD I don't
> have to do a clean, doing a bisect though I effective have to do a
> clean every new commit.

Well exactly, that's the stupidity of it. You always have to 'make
clean', "just to be sure", even if "most of the time" it works.  It's
2019, and algorithms for reliable builds have been known for at least a
decade or more, yet we're still stuck in the dark ages of "occasionally
I have to run make clean, and maybe I should do it right now 'cos I'm
not sure if this bug is caused by out-of-sync object files or if it's a
real bug".  Can you imagine how ridiculous it would be with the above
5-6 hour build script, if I had built that project out of makefiles?  I
would get absolutely nothing done at all if every once in a while I have
to `make clean` "just to be sure".

Thankfully, SCons is sane enough that I don't have to rerun the entire
build for months on end -- actually, I never had to do it.  Even when
there were big changes that cause almost the whole thing to rebuild, it
was SCons that figured out that it had to rebuild everything; I never
had to tell it to.  Every time I build, no matter what state the
workspace was in, it would always update everything correctly.  I can
even `git checkout <branch>` all over the place, and it doesn't lose
track of how to update all relevant targets. I never have to hold its
hand to get it to do the right thing, it Just Works(tm).  *That's* what
I call a sane system.  (In spite of said SCons warts.)


> > There's more I can say, but basically, this is the power that having
> > direct access to the DAG can give you.  In this day and age, it's
> > inexcusable not to be able to do this.
> > 
> > Any build system that cannot do all of the above is a crippled build
> > system that I will not use, because life is far too short to waste
> > fighting with your build system rather than getting things done.
[...]
> The build systems I've used can do all that, the problem is about
> functionality so much as the ease of achieving that functionality.

Well, yes.  That's why I repeatedly say, a proper design should empower
the user.  Easy things should be easy, and hard things should be
possible.  It shouldn't be the case that easy things are hard (e.g.
Manu's "if I have to run an extra step before compilation, I have to
bend backwards and recite gibberish in encrypted Reverse Klingon to get
make to do the right thing"), and hard things are either outright
impossible, or practically impossible because it's so onerous you might
as well not bother trying.


> I just use a script, don't need a build system but doing a fully build
> of my project only takes 10 seconds so I have that luxury.

As I said, my website project takes about 5-6 hours for a full, clean
build.  Anything less than a sane build system -- or a mostly-sane one
(SCons does have its warts like I said) -- is simply not even worth my
consideration.  Life is too short to have to take 6-hour coffee breaks
every other day just because make is too dumb to produce reliable
builds.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL