Live data from Hacker News

Makefiles for web work

rosszurowski.com

21–30 of 58 posts

Re: Makefiles for web work

#21
post #2

Just [0] was discussed on HN. I think I'll give that a shot next time I have to write something like this. .PHONY is lame. [0] https://news.ycombinator.com/item?id=34315779

I strongly recommend `just`. I used it successfully with projects written in OCaml, Rust, Go, Elixir and Lua. Define a few tasks, give them 1-2 character aliases, profit.

Super ergonomic.

Though I have to admit, Go and Rust projects hardly needed `just`; the `go` program and the `cargo` tool are that good. I used `just` in them mostly to have short aliases and common names for tasks.

Re: Makefiles for web work

#22
post #13

I’m unconvinced. I don’t see a reasonable benefit for learning yet another config syntax just to run some scripts.

That's specifically the gain here, you don't need to keep learning new build tools or language-specific tools. Make works for all languages, all kinds of projects, has been around since forever and is not going away. It's the only build tool you need to learn.

`just` does the same but better, is much quicker to learn (we're talking literal 5-10 minutes), and doesn't have decades of weird syntax baggage.

Re: Makefiles for web work

#23

>People routinely point out that npm/yarn scripts are shockingly slow to start The claim that 157 ms and 126 ms is "shockingly slow" is quite an exaggeration.

It's not an exaggeration when you inevitably end up chaining them. The overhead adds up very quickly and becomes noticeable.

Also they take even longer to start in CI/CD containers.

Re: Makefiles for web work

#24
post #3

My main problem with make: When you want to write sophisticated build processes, the syntax is bizarre and difficult to work with.

Not only that, but look at any advanced-age project that uses make. There are layers of includes, and defines and rules are smeared across multiple files.

I think many modern web-build tools were made by people who thought "hey, I can do better than make" (or worse, "What's make?" and reinvented the wheel) and then wound up in a similar conundrum.

Re: Makefiles for web work

#25
post #8

Make becomes a pretty terrible tool at a fairly low level of complexity. I would never choose it voluntarily to build things.

I agree. It has its merits, but it's hard for me to get around my visceral reaction to the fact it just bombs on filenames with spaces in them.

You can escape spaces in makefiles.

Re: Makefiles for web work

#26

I tried repeatedly to just stick with Makefiles but I kept having to add workaround and hack to do basic stuff. They got uglier and uglier. I checked out go task and cargo make, but eventually gave in to `just`. It has worked just fine and the files are infinitely more readable than the comparable ones w/ make.

What kind of workarounds and hacks? Make's task interface is essentially "anything you can do at the command line", generally with the same syntax (though you have to put extra parens around your variable names).

It's true that more modern tools have features make doesn't (especially with regard to manipulating complicated dependency graphs) or attack parts of the problem that make doesn't (hermetic build environments, language-aware features like package management).

But... I can't see "lack of ability to do basic stuff" as one of its problems. What basic things are you trying to do?

Re: Makefiles for web work

#28

>People routinely point out that npm/yarn scripts are shockingly slow to start The claim that 157 ms and 126 ms is "shockingly slow" is quite an exaggeration.

It's not an exaggeration when you inevitably end up chaining them. The overhead adds up very quickly and becomes noticeable. Also they take even longer to start in CI/CD containers.

true, but the moment you add containers to your mix you're functionally admitting that you don't care about startup times. Or possibly, you've been forced to do it by some service provider who doesn't give you a better option...

Re: Makefiles for web work

#29
I've done things this way for many years but now that I'm working with rust I find myself doing more with cargo instead.

Compared to make, one thing I like about cargo is I don't need to worry about the current directory as much. e.g. "cargo check" works from anywhere in my workspace but something like "make check" will fail if the Makefile isn't in the current directory.

Yes I know I could probably create an alias, direnv or something to improve make's behavior but I'd rather not have more things to manage. All this stuff is too complicated as it is. Overall the cargo defaults are much more ergonomic.

Re: Makefiles for web work

#30
post #26

I tried repeatedly to just stick with Makefiles but I kept having to add workaround and hack to do basic stuff. They got uglier and uglier. I checked out go task and cargo make, but eventually gave in to `just`. It has worked just fine and the files are infinitely more readable than the comparable ones w/ make.

What kind of workarounds and hacks? Make's task interface is essentially "anything you can do at the command line", generally with the same syntax (though you have to put extra parens around your variable names). It's true that more modern tools have features make doesn't (especially with regard to manipulating complicated dependency graphs) or attack parts of the problem that make doesn't (hermetic build environment…

GNU Make only recently added any support for rules which produce multiple targets.
Post reply on HN