Makefile experts, unite!

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Mon Jun 12 10:39:03 PDT 2017


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

-- 
Жил-был король когда-то, при нём блоха жила.


More information about the Digitalmars-d mailing list