On Mon, Jun 12, 2017 at 06:09:52PM +0100, Russel Winder via Digitalmars-d wrote: > On Mon, 2017-06-12 at 13:18 +0200, Jacob Carlborg via Digitalmars-d > wrote: > > […] > > > > But I rather see the make build system completely replaced with > > something else.
+1. > Make was a revelation and revolution in 1977. > > Make is the assembly language of build. > > There are much better abstractions of build these days. > > CMake/Make > CMake/Ninja > Meson/Ninja > SCons Don't forget tup, and others inspired by it, which use modern OS features to reduce the cost of determining what to build to an O(1) database lookup rather than an O(n) whole-source tree scan. I.e., much faster code-compile-test cycle. Much as I have come to love SCons, I think ultimately the build system of the future will be something derived from the tup model. [...] > That Chapel and D chose Make as their build system is rather annoying, > so backward looking, for supposedly forward looking systems. Oh well. [...] I don't agree with the notion that everything must be "forward looking" in order to be "good". If something existing works well and does what we need it to do, there's no reason to keep reinventing the wheel. However, I do agree that where there is room for improvement, improvements ought to be made. On this front, make leaves a lot to be desired. It requires far too much babysitting, manual work, and dependence on human infallibility (which we all know works all too well). Not to mention that it fails the basic tenet of a reliable build system: reproducible builds, i.e., given *any* arbitrary workspace state, running the build command ought to produce products (executables, etc.) that are *guaranteed* to reflect the current state of the source code. Just working with a dmd PR these past few days brought me right back to the bad ole days of always running `make clean` before `make`, just to be sure that the executables accurately reflect the source. I had shed such redundant steps long ago when I adopted SCons as my go-to build system, but it didn't take long working with the dmd sources to discover that sometimes make doesn't produce the correct executable, but picks up detritus from the environment (stale object files from previous builds, temporary files that the bash script snippets expect to be absent or don't expect to be still lingering, etc.). (It's not as bad in druntime/Phobos where all the makefile does is basically to pass all the source files to a single invocation of dmd. More or less. But if you have to work with documentation or running the test suite, the flaws of make surface all over again pretty soon. Updating the interminable lists of files in posix.mak, for example, is quite reminiscient of working with a C source tree that's heavily dependent on leaky macros. Quite the nostalgia trip, I have to say.) One can always argue that make is time-tested and everybody knows it, therefore it can't be all that bad. Well, programming in C is also time-tested, a large number of veteran programmers know it, so it can't be all that bad, can it? I mean, all you have to do is to make sure your arrays are never overrun, avoid poorly-designed standard library features that lead to security holes, make sure you manage your own memory well to avoid leaks and double-frees, make sure your pointers are always valid, make sure you don't write leaky macros, memorize the operator precedence table, learn the intricacies of 100 different gotchas that can come back and bite you in the behind, and ... There's really no need to program in another language, like D, right? :-P Another common objection is, there's no clear "winner" among the make alternatives to have an obvious choice to pick, so we better just stick with make for now. Well, arguably, from a certain perspective, there's no obvious "winner" among successors to C/C++ either... there's D, Go, Rust, Java, etc.. So let's just stick with C, the lowest common denominator, until a clear winner emerges. T -- Жил-был король когда-то, при нём блоха жила.