7 ms·
The author is not even using the mtime-based dependency tracking. Also the targets are supposed to be PHONY but not marked as such. The author could have replac
by kccqzy 2y ago
The author is not even using the mtime-based dependency tracking. Also the targets are supposed to be PHONY but not marked as such. The author could have replaced it with a shell script that read $1 and matched on it to determine what to do.
- notpushkin 2y agoHere’s a one-line horror story for you (from a real project I’m working on): .PHONY: $(MAKECMDGOALS) > The author could have replaced it with a shell script that read $1 Sure, but `./build.sh dev` is a bit less obvious than `make dev`. Another reason to use Make even if you don’t have any non-phony steps is that you can add those later if needed. (I agree that the author should mark {dev,build,deploy} as phony though.)
- dima55 2y agoI got an even better one for you: `./dev.sh`. The author is doing it wrong, and giving Make a bad name.
- notpushkin 2y agoYou’ll also want ./build.sh and ./deploy.sh then. If each is 1-2 commands, I’d argue it’s a waste to use separate files here. > giving Make a bad name How so?
- Jach 2y agoThat's fine, the separate files are a benefit here. The only annoyance is clogging up the root project folder -- though some people don't seem to care about that. If they got too numerous (the 5 in OP's "more advanced" project would probably not be too numerous), I'd consider putting the scripts in their own folder. I might even call it 'make' just to mess with people. Then my commands are just make/build and make/deploy and so on (.sh unnecessary). But really, in OP's case, I just have no need for some of their simple wrappers. "npm run dev" is two characters longer than "make dev", pointless.
- dima55 2y ago> I’d argue it’s a waste to use separate files here Fine. Write a `make.sh` that parses the arguments; that would be better. > How so? Well, read the comments here. Do you sense that Make is a beloved tool? Most of the complaints are about some details about syntax, and those complaints are completely valid. If you use Make for its intended purpose, then it's still easily well-worth using, despite that. But if you use it as a glorified script, then all you see is the warts, without any upsides. And you then tell all your friends that "Make sux!" Which is a huge shame because Make is awesome.
- tpoacher 2y agoHear hear!
- deleted 2y ago[deleted]
- jakelazaroff 2y agoFirst of all, misusing a tool doesn’t “give it a bad name”, and second of all who cares? A tool isn’t a human being. Make’s feelings aren’t going to be hurt by this article. The author just shared something they think is cool. That takes guts to show the world, and our critiques should respect that.
- tpoacher 2y agoWhy is this a horror story? Under certain assumptions of how the author intends to use this, this sounds like a sensible way to define a dynamic list of phony targets to me, without having to specify them by hand. There are many reasonable scenarios why you might want to do this: determining at the point of calling make which targets to force or deactivate for safety, projects with nested or external makefiles not directly under your control, reuse of MAKECMDGOALS throughout the makefile (including propagation to submakefiles), ...
- lloeki 2y agoConsider: .PHONY: $(MAKECMDGOALS) qux: foo: qux bar: foo Now make bar and make foo bar will disagree on whether foo is phony, which may or may not be what one wants depending on both what foo and qux do, and how bar depends on foo and qux side effects. It also very much depends on what the intent is, notably such a "autophony" make foo is very different from make -B foo.
- fukawi2 2y agoWhile you're technically correct, what I gathered from their experience is the consistency of usage, between not only their own projects but third-party projects too. They could make technical improvements to their own Makefiles, sure. But it's more about being able to enter a project and have a consistent experience in "getting started".
- ReleaseCandidat 2y ago> But it's more about being able to enter a project and have a consistent experience in "getting started". I'd say putting the Makefile content in `package.json` would be more consistent, especially as they are already using Gulp as the build system.
- croemer 2y agoYou can't put comments in package.json, JSON should never have been used for something maintained by humans.
- ReleaseCandidat 2y agoWe are not arguing whether not declaring phony targets is worse than using comments in `package.json`? But anyway, comments in a Makefile or `package.json` are not documentation anyway, that's what the `README` or `INSTALL` (or whatever) is there for (in projects like the one the Makefile is written for).
- weinzierl 2y ago"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. https://just.systems/ https://just.systems/
- a5c11 2y agoOr just with a simple command which is guaranteed to be on most Linux systems already - make. 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.
- hulitu 2y ago> but it works 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.
- wruza 2y agoI remember countless times me and forum fellas debugging makefiles written under developers’ assumptions about systems. That is also what lots of developers forget or simply aren’t aware of. 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.
- kaba0 2y agoMake leaves the actual hard problem behind — setting up the environment correctly. A README file is much more useful.
- weinzierl 2y agoThere was a time when people would have said the same about make. The shell is the simple command that is guaranteed to be on all Unix systems from the get go. Make is the new kid on the block. 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.
- tempodox 2y agoWe all were beginners at one time or another. And if you want to learn a tool, it helps to actually use it, even if your greenhorn usage is less than perfect. You can make incremental improvements as you learn, like we all do.
- deepspace 2y agoThe author also seems not to have discovered 'make configure' and the horrors of the automake/autoconf toolset and the m4 macro language.
- ristos 2y agoThat's the beauty of make and shell, it's follows the UNIX principle of being simple and doing one thing and one thing well. People want it to do many other things, like be a scripting language, a dependency tracker, etc, so they're willing to pull in bloatware. New isn't necessarily better. Autoconf and automake isn't make.
- trashburger 2y agoIs this satire? Being a scripting language and tracking dependencies are primary features of shells and Make, respectively.
- ristos 2y agoNot satire, sorry I didn't clarify. They want make to have a builtin scripting language rather than using shell scripts, and a dependency tracking system that more complex and less tooling agnostic rather than leveraging the appropriate tool (like `npm ci`).
- kaba0 2y agoNone of them are simple, they are chock full of hacks upon hacks, “fixing” their own idiocies, and by extension, none of them are doing their one thing well. Especially bash scripts, they should be left behind..
- ristos 2y agoCan you be more specific what you view as hacks or idiocies? Besides the criticism of .PHONY targets, which I don't think is a hack nor particularly ugly. When I mean shell I'm referring to a family of shell languages that are used run commands, change directories, etc. Fish is a shell, for example. Babashka can be considered to be a shell. It doesn't even need to be those, someone using make could use python or javascript for the scripting part if it works better than a shell language.
- unscaled 2y agoYes, the UNIX principle of being simple and doing one thing and one thing well. Make does dependency tracking relatively well (for 1976). But if you just want to run some commands, your shell already does that just as well, without any of the caveats that apply to make.
- thom 2y agoThere isn’t even a need for a shell script. The author is already invoking three separate tools, each of which has a mechanism for invoking custom commands.
- oblio 2y agoWhat if he wants to have a uniform environment across projects and some aren't JavaScript?
- scrame 2y agoDear God! There is something that isn't javascript? Do you know you can it use on the server and the browser!??!
- thom 2y agoThen he could just use Gulp, but I have no skin in this absurd game.
- oblio 2y agoGulp? That JS tool that was last cool in 2018? After it which it was replaced with Grunt, which stopped being cool in 2020? And that was replaced with Webpack, ESBuild, Rome, Bun... Why would anyone voluntarily subject themselves to that kind of insanity? :-)) Better to just use the hacksaw that is Make than all these Rube Goldberg contraptions :-)
- thom 2y agoI don’t personally care about the JS ecosystem. But OP is already using Gulp. He’s then calling Gulp from npm run. He’s then calling npm run from make. Adding make into the mix is solving nothing here. If you’re saying he should use make properly I agree!