Make vs. Tup (2016)

This reminds me on &#x27;Make vs. X&#x27; trend some years ago, where Make would be bashed how is slow, not extensible, had weird syntax and incompatible between implementations. So we got alternatives like Aegis[1], Scons[2], A-A-P[3] or Jam[4] instead, which were much faster and flashier on paper.<p>But guess what, Make is still kicking, GNU Make got a bunch of new goodies (Guile scripting or loadable modules to name a few) and all those alternatives are pretty much dead now. What I see now is that we are repeating the same mistakes only with flashier tools (node, python3, rust).<p>Although I always preferred Jam[4], I&#x27;m pretty happy with GNU Make now. Not perfect, does the job well and if I ever hit some weird platforms, I can always &#x27;extend&#x27; myself to Autotools[5]. Funny thing, I&#x27;m even using Make to run Ansible scripts or compile Java&#x2F;Clojure code and works like a charm.<p>[1] <a href="http:&#x2F;&#x2F;aegis.sourceforge.net&#x2F;" rel="nofollow">http:&#x2F;&#x2F;aegis.sourceforge.net&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;scons.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;scons.org&#x2F;</a><p>[3] <a href="http:&#x2F;&#x2F;www.a-a-p.org&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.a-a-p.org&#x2F;</a><p>[4] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Perforce_Jam" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Perforce_Jam</a><p>[5] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;GNU_Build_System" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;GNU_Build_System</a>

I found the Build Systems a la Carte¹ paper, and NDM’s companion write up² to be good comparison of build systems in a more general manner.<p>Caveat: It may skewed having been written by heavy Haskell hitters, and an author of Shake. I’ll note that I didn’t notice any bias, but maybe only because it aligned with mine ;)<p>1. <a href="https:&#x2F;&#x2F;www.microsoft.com&#x2F;en-us&#x2F;research&#x2F;publication&#x2F;build-systems-la-carte&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.microsoft.com&#x2F;en-us&#x2F;research&#x2F;publication&#x2F;build-s...</a> 2. <a href="http:&#x2F;&#x2F;neilmitchell.blogspot.com&#x2F;2018&#x2F;07&#x2F;inside-paper-build-systems-la-carte.html" rel="nofollow">http:&#x2F;&#x2F;neilmitchell.blogspot.com&#x2F;2018&#x2F;07&#x2F;inside-paper-build-...</a>

What I&#x27;ve seen of Tup is good but it doesn&#x27;t add enough to convince me to switch away from make which is already everywhere.<p>CMake and similar tools don&#x27;t attract me because they&#x27;re not language independent. The best thing about make (and Tup too) is that it lets you express dependencies and ways to satisfy them in terms of other tools.<p>Now what make is not good at is being .&#x2F;configure. I&#x27;d like to see a more elegant autoconf-like tool to detect things about the environment and generate configure.{h,mk}.

My two favorite make alternatives make HN in two consecutive days.<p>I like redo because with make you need to know two languages, with redo you know just one, the interface is simple and you get automatic dependency on build rules for free. Also the implementation is so much simpler than make, and yet I&#x27;ve not run into a feature I miss from make.<p>I like tup because it is very opinionated and forces you to write your build scripts in a reasonable manner, while also being very fast and very correct. It might be possible to write a tup file that incorrectly handles dependencies, but you&#x27;d have to work hard to do so.

Anyone aware of an npm library that wraps tup to provide automatic dependency graph construction from objects changing on filesystem?<p>I&#x27;d could use a javascript api that enabled automatically detecting filesystem change dependency graph associated with each of a given set of javascript function calls ... Perhaps with simplifying assumption that all function parameters are serializable or maybe even that the functions being tracked are only allowed to operate on strings that represents filesystem path&#x27;s ...<p>I&#x27;d love for the functionality implemented within tup of running a command and automatically doing the low-level kernel hacking necessary to track all the filesystem objects read&#x2F;written to be abstracted into an application-level library ...

tl;dr: for the vast majority of projects, tup does not outperform make.

There was a good post yesterday about redo.<p>I&#x27;m all for good build systems and I have used make quite a bit but the problem in moving to a better build system is that makefiles are so convoluted and hard to reason about that nobody wants to be blamed for breaking the build by migrating.<p>I wish there were a testing system for builds. Specify updating what should change what and check timestamps (to begin with) of created files.