Use `make` to save time

"Make" is great for small projects. But as the project grows people start to fill the Makefile with hacks: all those empty files with "stamp" in the name and scripts called "move-if-change" and other tricks that don't quite follow the rules. And recursive "make" invocations (http://aegis.sourceforge.net/auug97.pdf). Eventually the whole thing becomes so incomprehensible and unreliable that the general advice becomes: do a fresh a checkout before running "make", or build out-of-tree and do "rm -r *" first. You almost certainly have to do that if the stuff you're trying to debug is the build infrastructure itself, which, sadly, is something developers spend an awful lot of time doing.

Don't get me started on Makefiles that invoke Docker.

Some practical advice: don't write a rule like "./script < input > output"; instead write "./script < input > output.new && mv output.new output". That way if the script fails it doesn't leave things in a broken state with "output" appearing to be up-to-date. Perhaps a replacement for "make" would incorporate this mechanism?

A replacement for "make" would also have a proper way of handling the situation in which a file is regenerated and found not to have changed, to replace all those half-working "stamps" and "move-if-change" hacks.

Edit: See also: https://www.gnu.org/software/automake/manual/html_node/Multi... Presumably a decent build system would make this fairly normal situation somewhat easier to handle.

As much as I love unix philosophy and tools that follow it, I would point out that using the build tool that comes with the language is usually the better option.

Nobody would use make instead of maven [1] with Java for example. Ruby uses Rakefile instead of Makefiles. You will probably confuse lots of developers that work on your project if you do that.

On top of that Makefiles are known to be generated these days ( CMake ).

1 : https://stackoverflow.com/questions/2209827/why-is-no-one-us...

You have noticed a small bug in your data processing script and now you have to redo all your plots for your thesis? latex+gnuplot scripts+makefile, and a few seconds later you have a new pdf.

Make is an amazing tool! It gives you a lot of power with just a few new concepts to learn.

However, I don’t see much value in using make as intended in the article. The author uses it as some sort of “shared bash history” for developers, where it is used to store the most relevant commands for a project.

Make is good for keeping track of what changed in your environment and, when it does change, to do the least amount of work necessary to build your asset. For the problem that the author is trying to solve, I would recommend something like Ansible, which feels simple and its playbooks often serve as documentation.

Why would anyone advise using GNU make instead of cmake? It is well known that make itself is insufficient for complex builds. This led to development of meta tools like GNU autotools and cmake. I would argue that cmake is better and saves time over using autotools.

That said, I am really impressed with Google’s meta tool called GN which generates scripts for a build system called Ninja. This tool chain is based on performance, and the scripting is much easy/less ugly than cmake.

I’ve been using make for packaging and deploying a variety of AWS CloudFormation stacks and it’s been working pretty well. I use ‘make package’ to generate a final deployment file and run any transforms needed, and then I can run ‘make deploy’ to actually build the stack. It’s been a pretty smooth workflow and I prefer it over the mess of bash scripts we had before (though I know they are different tools with different purposes).

" But show me a better tool for actual development workflow automation and I’ll be glad to switch."

Perhaps Snakemake? I've been using it recently in Bioinformatics and I love it. It works perfectly on our Torque/qsub cluster but can also easily switch to a set of dockers in the background.

I think there's a bug in this page, I'm not seeing code snippets that are referred to in the text. Shame, because I want to point coworkers at it.

As a user, what I really miss in a lot of make replacements is an obvious way to install a custom location.

Something like ./cofigure --prefix=/usr/local/foo

Another thing I miss is the ability to easily pass in custom compilation options, like: CFLAGS="-O0 -ggdb3" LDFLAGS="-L/usr/local/foo/include" ./configure

I know these are features of autotools I'm talking about, not of make per se. Still, a lot of tools that are supposed to be way better than make and autotools just seem to assume every user's going to install in the same location and offer no obvious way to give different compilation options and as a user it's really frustrating because I need both all the time.

Many other programs use make, and so I use make for compiling those programs. For my own programs I do something different (unless it is a modified version of another program that already uses make).

For programs with a single file, I might add something like this at the top:

  #if 0
  gcc -o ~/bin/program program.c
  exit
  #endif

For programs with multiple files, I will write a shell script to figure out and compile everything (but use stuff like the above to compile each individual file). Although, I should probably make a better way, later.

I used make for several years, but switched to rake and never looked back.

Martin Fowler put together a nice article about rake:

https://martinfowler.com/articles/rake.html

If you deal a lot with artifacts you need to download from random places (ala maven, but with a lot more flexibility), or produce artifacts to various repos, buildr is very nice.

My only gripe about make (I use gnu make almost daily) is so far I haven’t discovered a good way to test posix make functionality. The .POSIX special target doesn’t really make gnu make follow posix strictly.

Try ‘quit’