Have Win DMD use gmake instead of a separate DMMake makefile?

[H. S. Teoh]

On Mon, Aug 12, 2013 at 05:44:35PM -0700, Walter Bright wrote:
> On 8/12/2013 5:19 PM, H. S. Teoh wrote:
> >>5. Do we really want D to be restricted to only platforms that have
> >>the latest Python up on them?
> >
> >I think that's a bit of hyperbole. It's the same as saying "do we
> >want D to be restricted to only platforms that have g++/make
> >installed?"
> 
> No, I don't think it's hyperbole. I would bet that a C++ compiler
> (which invariably come with a make) exists on essentially every
> platform 32 bits or larger. Python? Doesn't seem likely.

OK, perhaps the situation on Windows is far different from Linux, then.
I haven't used Windows in any significant way for over a decade, so my
perception is probably biased.


> >If we have a D build tool that we ship with the dmd sources, then we
> >will have (1) a superior build system to make, (2) no external
> >dependence on gmake / python / whatever else. Since we're aiming for
> >dmd to be itself written in D, we might as well just self-host the
> >build system too. And this tool can be used to build other D programs
> >in general, not just dmd / druntime / phobos.
> 
> I think you're underestimating the amount of effort needed to build a
> "proper" build tool, even to get it up to the level of make. For
> example, gmake has the -j switch, enabling building using all the
> cores on your CPU. This is a big deal, but I don't think it's so easy
> to create a bug-free implementation of it.
> 
> (DM make does not have -j.)
[...]

SCons supports -j out of the box. You don't even need to write your
build rules differently, as you must in make to get it to work properly.

Of course, that doesn't really say very much about how much effort it
took to implement that. But in this day and age, any build tool that
can't parallel build *by default* is simply not worth the effort --
might as well go back to make.

One interesting approach is in tup (http://gittup.org/tup/), which
actually sandboxes each build command executed, so that it can determine
the exact inputs/outputs. This leads to nice features like, when you
update your system libraries, it will know to relink your program, or
when you #include or import stuff, it knows which exactly files the
compiler read (instead of trying to guess by scanning file contents,
which sometimes gets it wrong), so when those files are modified it
knows what to recompile.


T

-- 
By understanding a machine-oriented language, the programmer will tend
to use a much more efficient method; it is much closer to reality. -- D.
Knuth