Tl;dr it’s much easier to support non-unixoid platforms especially if your project is go-based. Also if you like go, you can probably write better go than shell.
Make isn’t used as much for building software now. We have systems on top of make (CMake), language-specific tooling (go) and cross-language build systems (Bazel). Make is used a lot as a lowest-common-denominator function runner. A “Make alternative” therefore needs to be trivial to install and low-overhead to write, qualities I don’t think Go has. The toolchain is almost half a gigabyte, and even with the Sh part of Mage, it’s a lot of syntax just to run some commands.
I use make directly, it works great. As to easy to install, this is as easy to install as any go package once you have go installed. It makes perfect sense for that use case, especially on windows.
What languages do you use it with? My focus is C/C++, which is pretty much the worst case for builds — the compiler doesn’t help with dependency management at all, there are many compilers with incompatible language feature sets and flags/options, linking tends to require a separate tool, lots of OS-specific issues with linking, etc.
For this stuff ‘make’ is like “the goggles, they do nothing!” CMake helps, but is awful in its own way; it’s like a DSL designed by Homer Simpson (to continue the metaphor.) I would so love something better. Apparently Zig actually works well as a C build system; I haven’t looked into it.
It’s not really Make if it doesn’t track file changes. It’s more like a fancy command runner. In that space, https://github.com/casey/just is pretty good. It’s Makefile but without the indent issues, and is not tied to a specific language like Mage.
In terms of lightweight dependency tracker, the “redo” family of tools is also interesting to look into. Eg: https://github.com/apenwarr/redo
The big (depending on your priorities) problem with just is that is uses system shell to actually run commands, which makes it tied to unix. Mage’s sh is independent from system’s shell and that’s a significant value add.
I’ve used rake for a few personal projects in various languages, and it works well. I stopped doing it when per language build systems became more popular
It wasn’t mentioned by the author, but another point of make not being portable is the differences between GNU and BSD make, and whether there are any differences between the “fragments” provided by the operating system that can be included in another makefile (e.g. .include <bsd.prog.mk>).
The problem with a ‘better make’ is that newer tools have shown that make was solving the wrong problem. There are two steps you need in building a project:
Configuring the build (how should the build be specialised for this OS / CPU? Can we find the dependencies? What optional bits do we want to build?)
Building the project (given some source files and rules, apply any that are out of date).
POSIX Make just does the second but no one actually uses pure POSIX make because it’s painful. GNU make and bmake both try to conflate these and so you end up with completely unmaintainable hellscapes such the GNUstep or FreeBSD build systems. Ninja tries to do the second and do it well. CMake tries to do the first and do it… not completely terribly. The combination lets me do what I want. In particular, having multiple configurations of a build that I can build independently (if your build system makes having Release and Debug builds side-by-side hard, it fails spectacularly), including things like having my build directories on a different filesystem to my source.
Make was never meant to do more that the second bit, but you’re forgetting something: in the context of software distribution the de facto way to use make is actually automake, which includes autoconf (what produces the bit most people will recognize from ./configure). That’s the part that does the first bit. It also does it pretty well in spite of its age.
CMake can also generate (POSIX) Makefiles. I’ve seen more projects that use autoconf without automake than use both and some very large projects that use just make with no separate step.
I’m a Windows contributor on a handful of Python repos that use make, and I agree that the experience is quite rough. I mainly try to read the Makefile myself, and run the commands that need to be run. While I’d love to find an alternative, I don’t think asking contributors to a Python project to install Go is a viable one.
I’m working on a build system that’s meant to be used for any language, any platform, including Windows, so I am curious what you would like to see in a make alternative beyond “sane Windows support”.
The premise on the website says that go is better than shell for handling complex tasks and I agree. However, all examples escape to shell for the build command which is ultimately what we want.
Same reason I wouldn’t pick make over bash anymore. I used Makefiles in the past because that’s the industry standard, but thinking about it, doesn’t make sense.
update: Okay, just went through non-unix platform support argument. That is valid I guess.
Tl;dr it’s much easier to support non-unixoid platforms especially if your project is go-based. Also if you like go, you can probably write better go than shell.
Make isn’t used as much for building software now. We have systems on top of make (CMake), language-specific tooling (
go) and cross-language build systems (Bazel). Make is used a lot as a lowest-common-denominator function runner. A “Make alternative” therefore needs to be trivial to install and low-overhead to write, qualities I don’t think Go has. The toolchain is almost half a gigabyte, and even with theShpart of Mage, it’s a lot of syntax just to run some commands.I use make directly, it works great. As to easy to install, this is as easy to install as any go package once you have go installed. It makes perfect sense for that use case, especially on windows.
I think you meant to say “I use mage directly”?
What languages do you use it with? My focus is C/C++, which is pretty much the worst case for builds — the compiler doesn’t help with dependency management at all, there are many compilers with incompatible language feature sets and flags/options, linking tends to require a separate tool, lots of OS-specific issues with linking, etc.
For this stuff ‘make’ is like “the goggles, they do nothing!” CMake helps, but is awful in its own way; it’s like a DSL designed by Homer Simpson (to continue the metaphor.) I would so love something better. Apparently Zig actually works well as a C build system; I haven’t looked into it.
No, I meant make. The comment I was replying to said no-one uses make directly (I paraphrase).
I do see the logic of use mage for go projects.
It’s not really Make if it doesn’t track file changes. It’s more like a fancy command runner. In that space, https://github.com/casey/just is pretty good. It’s Makefile but without the indent issues, and is not tied to a specific language like Mage.
In terms of lightweight dependency tracker, the “redo” family of tools is also interesting to look into. Eg: https://github.com/apenwarr/redo
Mage seems to track file changes similar to make.
Edit: Forgot to say that I actually agree that Magefile is not a great replacement for Make’s dependency management, which is way more comprehensive.
The big (depending on your priorities) problem with
justis that is uses system shell to actually run commands, which makes it tied to unix. Mage’sshis independent from system’s shell and that’s a significant value add.This looks cool, but I don’t want a bunch of dependencies on random people’s GitHub URLs in my build scripts??
If you don’t like to include urls, you can install the packages locally. If you don’t like random people, you’re all out of luck.
There is also Shake, which uses Haskell. The Haskell compiler GHC’s own build system (Hadrian) uses Shake.
Ruby includes a tool called rake, which can also be used for building software. mruby uses it as a build system.
I’ve used rake for a few personal projects in various languages, and it works well. I stopped doing it when per language build systems became more popular
It wasn’t mentioned by the author, but another point of
makenot being portable is the differences between GNU and BSDmake, and whether there are any differences between the “fragments” provided by the operating system that can be included in another makefile (e.g..include <bsd.prog.mk>).The problem with a ‘better make’ is that newer tools have shown that
makewas solving the wrong problem. There are two steps you need in building a project:POSIX Make just does the second but no one actually uses pure POSIX make because it’s painful. GNU make and bmake both try to conflate these and so you end up with completely unmaintainable hellscapes such the GNUstep or FreeBSD build systems. Ninja tries to do the second and do it well. CMake tries to do the first and do it… not completely terribly. The combination lets me do what I want. In particular, having multiple configurations of a build that I can build independently (if your build system makes having Release and Debug builds side-by-side hard, it fails spectacularly), including things like having my build directories on a different filesystem to my source.
Make was never meant to do more that the second bit, but you’re forgetting something: in the context of software distribution the de facto way to use
makeis actuallyautomake, which includesautoconf(what produces the bit most people will recognize from./configure). That’s the part that does the first bit. It also does it pretty well in spite of its age.CMake can also generate (POSIX) Makefiles. I’ve seen more projects that use autoconf without automake than use both and some very large projects that use just make with no separate step.
I’m a Windows contributor on a handful of Python repos that use
make, and I agree that the experience is quite rough. I mainly try to read the Makefile myself, and run the commands that need to be run. While I’d love to find an alternative, I don’t think asking contributors to a Python project to install Go is a viable one.I’m working on a build system that’s meant to be used for any language, any platform, including Windows, so I am curious what you would like to see in a
makealternative beyond “sane Windows support”.Why do this:
instead of this:
The premise on the website says that
gois better thanshellfor handling complex tasks and I agree. However, all examples escape to shell for thebuildcommand which is ultimately what we want.Same reason I wouldn’t pick make over bash anymore. I used
Makefilesin the past because that’s the industry standard, but thinking about it, doesn’t make sense.update: Okay, just went through non-unix platform support argument. That is valid I guess.
hard pass from me. It seems to just make it worse to me.