6 ms·

Very nice. Whenever I see comments about people trying to reinvent make, my conclusion is that make "as a tool" is inevitably far superior, but people are most

Very nice. Whenever I see comments about people trying to reinvent make, my conclusion is that make "as a tool" is inevitably far superior, but people are mostly familiar with a small subset of its functionality, which makes it appear clunky. That, and the syntax is very flexible, which means it can easily be abused to write ugly/convoluted makefiles. If I had one thing I'd want to improve about make, it wouldn't be the tool itself, but its documentation, and a set of reasonable defaults/templates, like you have here. The documentation is amazing in one sense, in that it's very comprehensive, but very clunky and hard to master in another, in that it's organised in a very high-level manner that doesn't allow it to be used as a quick reference / point of truth, if you don't know what you're looking for. I found myself making anki notes for it, as it's not organised in the kind of way that would simply allow me to refer to the docs for your usecase and get things done. You really either know some functionality exists and can look it up or you don't, and unless you're someone who uses make in expert mode on a daily basis, it's hard to know all the specialised components and be able to combine them all together seamlessly. Hence my anki notes, hahah. But make really is an amazing tool. I wish people focused on improving make workflows instead of reinventing the wheel all the time with other tools (which are then forced on the user).

frankjr 2y ago
> Whenever I see comments about people trying to reinvent make, my conclusion is that make "as a tool" is inevitably far superior, but people are mostly familiar with a small subset of its functionality, which makes it appear clunky. If you're looking for a task runner, not a build tool, then make is not "far superior" in any sense and there are much better alternatives, the most prominent probably being "just". Even something as basic as accepting parameters to a task (make fetch <arg1> <arg2>) is awkward because make doesn't understand this syntax and interprets the arguments as targets. The only way to make it work is either through named arguments or empty target hacks and in both cases you need to write the validation logic yourself. In just it's simply: fetch PACKAGE VER: @echo fetching {{PACKAGE}} at version {{VER}} $ just fetch foo error: Recipe `fetch` got 1 argument but takes 2 usage: just fetch PACKAGE VER $ just fetch foo 1.2.3 fetching foo at version 1.2.3 https://just.systems/man/en/chapter_1.html https://just.systems/man/en/chapter_1.html
- nrclark 2y ago
  Just is fine, don't get me wrong. But Make targets can take arguements too. They just have to be named, or (if you stretch the definition a bit) wildcard targets. AFAIK, Just doesn't have any way to mark "this task is complete, so don't re-run it". It also doesn't have file-based dependendicies, which are pretty common for any kind of programming. Why would I want to lose all of Make's flexibility and power in exchange for slightly prettier UI syntax?
  - frankjr 2y ago
    > AFAIK, Just doesn't have any way to mark "this task is complete, so don't re-run it". It also doesn't have file-based dependendicies, which are pretty common for any kind of programming. That's fair but also not what I'm looking for in a task runner, that's why I explicitly said "not a build tool", which to me this falls under (although I realize everybody has a different definition of these terms and where they draw the line if at all).
  - maccard 2y ago
    I think this post is well intentioned but misses the point entirely. GOOS=darwin GOARCH=arm64 go build -ldflags="-X 'main.Version=v1.2.3'" Executing this with variables for os/arch/version is not straightforward in a makefile. You might argue that it's a flaw with the `go build` command, but replace go with cargo/dotnet/maven and you have the same problem. > AFAIK, Just doesn't have any way to mark "this task is complete, so don't re-run it" What does a makefile look like for "install this list of dependencies with pip/homebrew/apt, and don't run it twice?" > It also doesn't have file-based dependendicies, which are pretty common for any kind of programming C and C++ compilers at this stage are the only places that I work with file based dependencies. Unless you explicitly declare all the headers as dependencies in a makefile, make won't rebuild a cpp file if you change a header. IME ninja (plus cmake to generate it) has entirely superseded make in this space. Tools and languages comes with it's own build tool (see above - go/cargo/dotnet/etc) or state tracking (docker) that break make's assumption of file based dependencies. > Why would I want to lose all of Make's flexibility and power in exchange for slightly prettier UI syntax? Because every make file I've ever used in recent memory has been 30% workarounds to avoid file based dependencies, and work around subtle footguns that make has, rather than actually doing what I want it to do - execute a build command.
TylerE 2y ago
Any tool that treats spaces and tabs differently is not sane.
- nrclark 2y ago
  Agreed, I don't like that about Make at all. But also it's never something I have to worry about. Pretty much every syntax-aware text editor knows how to handle Makefiles, and knows that recipe steps start with a tab (unless you change Make's default). So for me, that falls in the "ugly, but not really a usability issue" bucket. And Make's power/expressiveness is worth accepting a few "I'd have done it differently" syntax things.
  - TylerE 2y ago
    It always seems to bite when I've got nothing but an SSH link and a default vim install to hand.
    - nrclark 2y ago
      lol that's fair enough. This is a tangent and unrelated to Make - but I also find myself in that situation pretty frequently, since I do a lot of embedded systems and some CI/CD work. If you find yourself in that situation frequently, I'd recommend one of: 1. Use sshfs to mount your remote target locally on your dev machine, or: 2. Use vscode's remote-ssh mode (if the agent can run on your target). Vscode's remote-ssh mode is really nice. It's good enough that it single-handedly made me switch from my previous editor, and I wish that I knew more tools like it.

frankjr 2y ago

> Whenever I see comments about people trying to reinvent make, my conclusion is that make "as a tool" is inevitably far superior, but people are mostly familiar with a small subset of its functionality, which makes it appear clunky. If you're looking for a task runner, not a build tool, then make is not "far superior" in any sense and there are much better alternatives, the most prominent probably being "just". Even something as basic as accepting parameters to a task (make fetch <arg1> <arg2>) is awkward because make doesn't understand this syntax and interprets the arguments as targets. The only way to make it work is either through named arguments or empty target hacks and in both cases you need to write the validation logic yourself. In just it's simply: fetch PACKAGE VER: @echo fetching {{PACKAGE}} at version {{VER}} $ just fetch foo error: Recipe `fetch` got 1 argument but takes 2 usage: just fetch PACKAGE VER $ just fetch foo 1.2.3 fetching foo at version 1.2.3 https://just.systems/man/en/chapter_1.html https://just.systems/man/en/chapter_1.html

nrclark 2y ago
Just is fine, don't get me wrong. But Make targets can take arguements too. They just have to be named, or (if you stretch the definition a bit) wildcard targets. AFAIK, Just doesn't have any way to mark "this task is complete, so don't re-run it". It also doesn't have file-based dependendicies, which are pretty common for any kind of programming. Why would I want to lose all of Make's flexibility and power in exchange for slightly prettier UI syntax?
- frankjr 2y ago
  > AFAIK, Just doesn't have any way to mark "this task is complete, so don't re-run it". It also doesn't have file-based dependendicies, which are pretty common for any kind of programming. That's fair but also not what I'm looking for in a task runner, that's why I explicitly said "not a build tool", which to me this falls under (although I realize everybody has a different definition of these terms and where they draw the line if at all).
- maccard 2y ago
  I think this post is well intentioned but misses the point entirely. GOOS=darwin GOARCH=arm64 go build -ldflags="-X 'main.Version=v1.2.3'" Executing this with variables for os/arch/version is not straightforward in a makefile. You might argue that it's a flaw with the `go build` command, but replace go with cargo/dotnet/maven and you have the same problem. > AFAIK, Just doesn't have any way to mark "this task is complete, so don't re-run it" What does a makefile look like for "install this list of dependencies with pip/homebrew/apt, and don't run it twice?" > It also doesn't have file-based dependendicies, which are pretty common for any kind of programming C and C++ compilers at this stage are the only places that I work with file based dependencies. Unless you explicitly declare all the headers as dependencies in a makefile, make won't rebuild a cpp file if you change a header. IME ninja (plus cmake to generate it) has entirely superseded make in this space. Tools and languages comes with it's own build tool (see above - go/cargo/dotnet/etc) or state tracking (docker) that break make's assumption of file based dependencies. > Why would I want to lose all of Make's flexibility and power in exchange for slightly prettier UI syntax? Because every make file I've ever used in recent memory has been 30% workarounds to avoid file based dependencies, and work around subtle footguns that make has, rather than actually doing what I want it to do - execute a build command.

TylerE 2y ago

Any tool that treats spaces and tabs differently is not sane.

nrclark 2y ago
Agreed, I don't like that about Make at all. But also it's never something I have to worry about. Pretty much every syntax-aware text editor knows how to handle Makefiles, and knows that recipe steps start with a tab (unless you change Make's default). So for me, that falls in the "ugly, but not really a usability issue" bucket. And Make's power/expressiveness is worth accepting a few "I'd have done it differently" syntax things.
- TylerE 2y ago
  It always seems to bite when I've got nothing but an SSH link and a default vim install to hand.
  - nrclark 2y ago
    lol that's fair enough. This is a tangent and unrelated to Make - but I also find myself in that situation pretty frequently, since I do a lot of embedded systems and some CI/CD work. If you find yourself in that situation frequently, I'd recommend one of: 1. Use sshfs to mount your remote target locally on your dev machine, or: 2. Use vscode's remote-ssh mode (if the agent can run on your target). Vscode's remote-ssh mode is really nice. It's good enough that it single-handedly made me switch from my previous editor, and I wish that I knew more tools like it.