Why Not Make?

I don&#x27;t think Make is ideal, but:<p>1) It&#x27;s simple, standard, everywhere, and everyone knows it<p>2) I haven&#x27;t seen anything better. Most of the other systems are disastrously complex.<p>I certainly, never, in a million years would use an untested, untrusted, proprietary build system from a little startup which might go away tomorrow.<p>I do think there is room for Make 2.0. Not Make reinvented; just cleaned up, better for distributed builds, etc.

I just had to deal with a large, handwritten Makefile when trying to package and cross compile something for buildroot.<p>Turns out it was easier to learn to use cmake and rewrite the relevant parts of the Makefile than fix everything in the Makefile that didn&#x27;t work in a cross compilation scenario.

I feel like every single point against make in this article is considered a feature of make by many other people. But I guess more than why not, I’d like to hear more about what the alternatives are. I see this is an ad, and it implies but doesn’t say explicitly whether this product fixes all these issues, or what it actually does at all. People have been trying to redo make for decades, and despite all its warts (and it does have warts) so far it seems like nobody has been able to supplant it.<p>No sandboxing? This complaint amounts to “it isn’t pure”. There are reasons to allow reading a file in a build rule that isn’t a dependency. Allowing temp files in a multi-step rule without complicating or obfuscating the dependency graph is one of them. You can do anything you want in a build rule. How often is this flexibility actually a problem? If someone is reading from a file dependency without using make to depend on it, they already know they’ll get the expected behavior; failure to rebuild when the dependency changes.<p>Unportable caches is asking make to solve a problem that make wasn’t built to solve. And one could argue this isn’t technically a build system problem at all. Wanting network caching for multiple hardware configurations is reasonable, but isn’t what make is for.<p>No language abstraction is something I like about make. I use make for automating analytics and image resizing and all kinds of things that aren’t C++ specific. Adding language abstractions would bloat and complicate make.<p>Timestamps are faster to compute than hashes. Occasionally this matters a lot.

While make, for me, fell out of day-to-day use once C&#x2F;C++ projects waned, it&#x27;s still a great and powerful tool. I really appreciate its consistency to a Unix philosophy where it provides the essential feature of target building through dependencies but leaves so much of the heaving lifting through good ole &#x2F;bin&#x2F;sh.

Make is trash, but some in house tool made 2 weeks ago is guaranteed to be a worse choice. Just generate Makefiles with CMake like everyone else.

TFA makes a bunch of claims about the functionality of make being bad or dangerous but doesn&#x27;t really provide any backing scenarios to demonstrate why. E.g. where timestamps can bite you, how you can miss compiler flag changes, etc.<p>Without this, it reads as FUD.

What if the objections in the article were solved directly?<p>&gt; Writing a Large, Correct Makefile is Really Hard &gt; No Sandboxing<p>Would it be possible to track dependencies on a file level, simply declaring everything that gets read as a dependency? In the end, it is very likely that the generated artifact is different if any of the files touched to build it changes.<p>So, why not track open() syscalls made by make and its sub-processes? This obviously has some requirements towards the kernel to allow such tracking. It would also report helper files used by the toolchain and maybe even the code (executables and .so files) used by the toolchain, but one may argue that they are actually dependencies -- the artifact must be regenerated if the toolchain gets updated.<p>&gt; Caches are Not Portable<p>It should be considered first if rebuilding on each node is really that bad. Next, caches are non-portable by nature if they use different formats, or if dependencies that were used to build the artifacts are actually different on the various nodes. So this sets limits on cache sharing in principle -- but this has nothing to do with make.<p>&gt; No Language Abstractions are Provided<p>Not going to argue against that.<p>&gt; Timestamps, Not Hashes<p>Is there anything fundamental to make that requires the use of timestamps? Otherwise this sounds more like &quot;nobody has bothered yet to change make to use hashes&quot;.

I&#x27;ve recently started to build my own static website generator (I know, I know, there are already millions of them). I really just wanted something simple that would allow me to generate a few haml pages together and deploy on my DO droplet.<p>I thought about Make because I remembered reading a nice article about how great it is for this kind of stuff. During my research, I also looked at Rake, which is Make in Ruby. Since I was doing my project in Ruby, I felt it would be nicer.<p>I really enjoyed using Rake, it&#x27;s very nice and will definitely re-use it in the future. Martin Fowler has a great article[1] about Rake and how it compares to Make.<p>[1] <a href="https:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;rake.html" rel="nofollow">https:&#x2F;&#x2F;martinfowler.com&#x2F;articles&#x2F;rake.html</a>

I haven&#x27;t used make for years - but I miss the simplicity. It just does what it&#x27;s supposed to do, in plain text.

Make is fine: <a href="https:&#x2F;&#x2F;agottem.com&#x2F;weld" rel="nofollow">https:&#x2F;&#x2F;agottem.com&#x2F;weld</a><p>Stop inventing build systems.