> You can disable this behavior for specific targets using make’s built-in .PHONY target name, but the syntax is verbose and can be hard to remember.
I think this is overstating things a bit. I first read `.PHONY` in a Makefile while i was a teenager and i figured out what it does just by looking at it in practice.
Makefiles do have some weirdness (e.g. tab being part of the syntax) but `.PHONY` is not one of them.
Make is installed on Windows, if you install Microsoft's C/C++ dev stack (typically via installing Visual Studio). They just use nmake instead of GNU make. They also include Cmake these days, as it's the common cross platform option.
> You wouldn't use GNU Make (the thing that comes for "default" on Linux) with Python either.
But people do use Make all the time for Python projects - as a command runner. Pelican projects, for example, come with a Makefile to start the server, publish, etc.
The whole point of this submission is that many, many people use Makefiles not for incremental builds, but as a convenient place to store commonly used commands. And just is a better and simpler tool than make for that. If you're on Windows, it's a pain to install make, compared to installing just.
The manual states that "just is a command runner, not a build system," and mentions "no need for .PHONY recipes!" This seems to suggest that there's no way to prevent Just from rebuilding targets, even if they are up-to-date. For me, one of the key advantages of using Make is its support for incremental builds, which is a major distinction from using a plain shell script to run some commands.
Maybe it’s the stacks I’m using, but I’ve always had incremental happen with language-native tooling like `go` or `cargo`. So for me at least, having lazy eval features like that would be an unnecessary increase in scope and complexity. With Just, I can just throw together different commands and it just works cross platform. I love it.
I much prefer that than the other way, ie letting language tooling become command runners (looking at you npm). That’s the worst of both worlds.
> I’ve always had incremental happen with language-native tooling like `go` or `cargo`
That makes sense, but for me, Make is incredibly useful for incremental file processing outside of programming. I've written tiny Makefiles that use glob patterns to batch-convert thousands of SVGs into PNGs and WebPs, but only for the modified SVG files. I've used Make to batch-convert modified LaTeX files to PDFs and render modified Blender projects into WebM videos for the web. Rendering videos is very time-consuming, so only rendering modified video files is a huge win.
And then you go ahead and complain that it is poor at building.
If you need a build tool, don't use just. Use make or something else. The purpose of just is to stop putting non-build stuff in Makefiles. And of course, it has a nice set of features that make doesn't.
My first sentence was me quoting the Just manual and my second sentence was my observation about what that suggests. I wasn't asserting whether it's true or not, just sharing my interpretation, as I'm not familiar with Just.
> And then you go ahead and complain that it is poor at building.
I did not "complain" I stated that incremental builds, regardless of whether Just has them or not, is one feature I personally like about Make.
Going by the responses I received, Just does not appear to support incremental builds and a simple acknowledgement, minus the vitriol, would have sufficed.
The question is if those reasons are convincing to someone. The big advantage of Make is that it is probably already installed.