"The author could have replaced it with a shell script that read $1 and matched on it to determine what to do."
Or just with a simple command runner like just.
Or just with a simple command runner like just.
Maybe his Makefiles aren't complex, nor they seem to follow all the best practices invented by code gurus in sandals, but it works and, what's important, it works for him.
That it what a lot of SW developers forget: your code might be the best in the world, but , if someone is not able to build it, it is useless.
Make isn’t a silver bullet for builds. It isn’t even a bullet. Most software gets built from scratch and make’s deps graph makes little to zero sense in this mode. Make is a quirky poor dev tool footgun, jack of all trades master of none.
If you just want to run commands in the order written down, don't need the topological sorting feature of make and value ubiquity then a shell script is the answer.
If you are not stuck in the past and you truly live by the UNIX philosophy of doing one thing and doing it well, a command runner is the answer.
The command runner avoids the ton of foot guns both shell scripts (no matter which flavor) and make files have. just also brings a couple of features out of the box that would be very tedious and error prone that replicate in make and shell scripts.
I rewrote my makefile in PS and don't miss anything from make and have no regrets, as it is simpler now.
I don't particularly mind this use of make, but as an article on make it fails to exemplify what I think is its main purpose.
Make is from 1976. I don't think you can legitimately refer to it as that.
I don't have any of those concerns with GNU Make.
Just has quite a few features and it's at version 1.35.
That would've been a pretty short window of time since make first came out (according to wikipedia) in 1976.
I seem to recall it being praised very highly at the time as a great tool that saved many billable expensive CPU minutes and made a developer's job so much easier.
Until it doesn't. And then you really have to learn about PHONY targets, why and when there must be a tab and not spaces - good luck with an editor that doesn't treat Makefiles special and is configured to convert tabs to spaces.
Because it isn't fun checking if the whitespace at the beginning of the line is a tab or spaces. And as said, you must know when to use tabs and/or spaces in rules.
For doing such a simple thing as calling some commands, Make has way too many subtle footguns which _will_ bite somebody, someday. The problem (that's not a problém at all, that's a reason to celebrate!) is that most JS devs and users aren't used to Make, compared to e.g. C programmers. To rephrase: as someone writing C, you have to use something like a Makefile, as anything else (like scripts) gets unreadable and -usable quite fast. But if you can get away with a less complex solution, you should really use that instead of Make.
that's why https://editorconfig.org/ exists, so that neither you nor your teammates have to think about these things
You're better off using a Makefile linter. But you must know about the problem before being able to solve it. And error messages like
Makefile:2: *** missing separator. Stop.
Is that Stockholm syndrome? Or an appeal to history/authority in action? What makes people believe that this is even remotely reasonable.
inb kids these days, I started in the '90s and wrote my share of makefiles. Tolerating make only made sense until 2010-ish, then both hw and sw advances rendered it useless.
Edit: just realized my reply to a wrong person, but let it stay here
If you're using make a glorified task runner, why don't you just create a scripts/ directory with shell scripts to do whatever you want. This is simpler, cleaner and works everywhere.
Make doesn't really add anything. I get the feeling that using make this way is an aesthetic preference that has somehow developed with time into a "this is the one true Unix way" cargo cult.
1) It's already installed practically everywhere
2) It reduces your cognitive load for all sorts of tasks down to just remembering one verb which you can reuse across multiple projects, even if the implementation ends up differing a bit
3) In conjunction with the similarly ubiquitous SSH and git, you have everything you need to apply the basic principles of DevOps automation and IaC
There's something special about waking up one day with an idea, and being able to create a fresh git repository where the first commit is the Makefile you've had in your back pocket for years that scripts everything from environment setup to deployment to test automation to code reviews.
There's zero effort beyond just copying your single file "cookbook" into that new repo.
This always comes up, and is a sad chicken/egg problem.
We can all somehow agree that Make mostly sucks, but OS maintainers aren’t interested in providing a default alternative, due to choice overload or something.
Well, except Windows. But nobody uses that right?
2. nmake is with POSIX make, let alone GNU make. It doesn't even support .PHONY target, which is what you need to replace Just with make.
3. Installing Just with WinGet is simpler, faster and takes probably only 1% of the space of installing Visual Studio for nmake.
Neither is Make or GCC on Unix.
If it is a choice, it sort of shows an "I do not care" attitude to software development, or being seriously uninformed about proprietary software. Usually those are the types, for whom software engineering is merely a 9 to 5 job, and not a craft they take pride in. An activity they do not really care about at other times. Which is OK to do, not a crime. If I were hiring though, I would rather look for passionate software engineers/devs, who know a lot of stuff from tinkering and exploration. Ultimately using Windows means you are not truly in control of your productive system and are at the whim of MS. It is a risk no self-respecting software engineer should take.
To clarify, that is not to say, that there cannot be craftsmanship people using Windows. It is just way less likely. More likely they are "enterprise" software people. Even the choice to explore and use a GNU/Linux distribution betrays some kind of mentality of exploration. Wanting to know what is out there. Learning a new thing. Adapting it to ones needs. This kind of learning mindset in the long term is what sets engineers apart from others.
So I would claim, that not many good software engineers use Windows to be productive. If they have to, they will likely install some VM or some means of making things work as if they were on a GNU/Linux system. WSL or whatever, to circumvent the limitations and annoyances of a Windows system.
If there's craftmanship anywhere, its in game development, and they surely don't want to spend all their time working on a platform without proper tooling that their end users overwhelmingly do not use.
The choice of OS has nothing to do with craftmanship or "exploration". I "explored" linux many times and am not using it currently.
In fact, I'm happy to argue that most developers that care so much about the choice of OS that they are uninterested in using another one (and do not work in OS development) are probably somehow stuck in their ways and uninterested in exploration themselves.
Taken even further, currently the only important OS is the browser, and nobody cares who launches it.
I hope you are not somehow in charge of hiring.
But of course, if you want all the IP to leak via MS spyware phoning home, sure, let your devs work on Windows machines.
I think neither take is true, nor does it hold much value to claim it, unless your aim is to divide developers into arbitrary adverse tribes.
* All commands in one place, view them all with `just --list`
* Stupid-simple format
* Small standalone binary
* Configurable (with arguments, environment variables etc) but not _too_ configurable
When I see a git repo with a Makefile, I'm filled with dread. When I see a repo with a Justfile, I get warm fuzzies.
Some people say it just doesn't do enough to justify existing. These people are just wrong.
Another benefit is that justfile just cannot get too complex and tangled. Simplicity at its finest.
I wish there was a flag for make which set it to be a command runner by default for the current makefile.
The whole difference of Makefiles, their original idea was to not re-compile a target _file_ if it's already there. So if you need .PHONY -- you're using Makefiles wrongly.
This is a sect and global trend to reinvent and re-implement the wheel with the Rust :D
[macos]
# do a thing