Build tools: Mage vs Make

A lot of the tooling around Gotham is inherited from Hugo. There’s many decisions that they’ve made that aren’t easily accessible. This can make it difficult to determine why something was used or why something was done in a certain way. I wanted to have a quick discussion on Mage and see if this is something we should continue to use, or to switch to using Make and a Makefile.


Make has been around for awhile and is sort of an unofficial standard. Many, many projects of all sorts of languages use Makefiles in order to build their source. For GNU’s release of Make, you can find more information here.


Mage was created in 2017 as a Rake-like alternative to Make. The idea is that instead of a Makefile, you have magefile.go. It serves the same purpose but written in Go, the same language that your project would be in. Their website can be found here.

Make vs Mage

So what do we do for Gotham, keep using Mage or switch to Make?

Switch to Make

Here’s why I think we might want to switch to Make:

  1. It’s not written in Go. This may sound like a con for Make instead of a pro but I don’t think so. The fact that Make is a standalone tool that works with multiple programming languages is a positive to me. It’s a tool you can learn once and use across various projects. Mage has to be used with Go projects only.
  2. Related to the previous point, Make is more well known. It’s more likely that incoming contributors will already know it. This means a lower learning curve for devs new to Gotham development.

Stay with Mage

  1. Hugo, Gotham’s upstream project, already uses it. It’s less work to simply stick with what we have. Not just the work to implement Make, because I don’t care about that. The work dealing with conflicts if and when Hugo updates their Mage file.
  2. Better integration with core Gotham code. Since Mage is written in and uses Go, this provides 1st class integration with the actual source code of Gotham.
  3. Make isn’t a native tool in Windows. Since Mage is Go, and thus compiled on the local machine, it can work on Windows the same as it would on Linux or Mac.

Thoughts? I can be swayed, but I am slightly leaning towards sticking with Mage. Not only does it have more pros than Make in this post, but point 3, the cross-platform capabilities, is the most useful thing I think we can get from these tools. While we don’t provide Windows binaries right now, we will soon. If we can make it easy for Windows devs to contribute to the project, that’s a great thing.

cc @chayev

Thank you for the details! Helps understanding what you are thinking through.

I’m leaning towards agreeing with you on this as well. It seems like sticking with Mage has more benefits.

I’d like to add a few more points here that you didn’t call out:

  • Make comes preinstalled on unix computers, meaning there isn’t a need to install anything to use it (outside of Windows). Mage needs to be installed.
  • Mage allows for multiple magefiles, this is not possible with Make.

While the first point seems like a pro for Make, I actually think the fact that Make is not well supported on Windows is a big deal. Installing Mage is not a big deal.

Lastly, I agree with your point about dealing with conflicts from upstream anytime they update their Mage file. I think this outweighs any benefit of using Make as well.

If you mean Unix-like, that’s not true. Ubuntu for example, the most popular Linux distro doesn’t include it by default. I don’t know about Macs.

The point you brought up about multiple Mage files actually means this can be even better now. We can make a separate file just for us without touching theirs. (though we already started to)

It came pre-installed on my computer, so I believe it does. Couldn’t find a resource online to be sure.

We still can!

So we should stick with Mage. We can make our own Magefile, the first target I’d like to have is “uninstall”. Since it can apply to upstream as well, I opened a PR:

If that doesn’t get merged in the next couple weeks, I will start our own Mage file with that target.

1 Like

Just wanted to follow up and say that it was merged upstream.