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