I went through my Makefile stage. It can be nice but it can also get messy and ugly. If you're doing simple tasks fine but your project still needs to have a lot things anyways that negates its usefulness.
Makefiles for web work
41–50 of 58 posts
Re: Makefiles for web work
#42I tried this for a bit until I found out make couldn't deal with spaces in the file name. switched to rake (ruby), which had the advantage of not needing to write separate shell scripts.
Why do you have spaces in the filenames of your project in the first place? They require annoying escapes to work with essentially everywhere, notably including on the web. You have complete control over the filenames in your project... why are actively choosing to use a space character? I can see a better argument for wanting to use an apostrophe in a filename than a space character :(.
Re: Makefiles for web work
#43Earlier quoted context omitted.
I generally find shell/npm scripts work until you get to the few cases that actually benefit from the dependency management and then you wish you'd just given in to .PHONY, no matter how inelegant it may be.
All of my dependency management issues are handled by npm. The main problem `make` solved was not wasting work rebuilding dependencies that hadn't changed, but in 2023 on modern computers I don't notice the CPU cycles burned on that kind of thing. (... if I do start to notice them, I reach for a tool like bazel, because it can handle spaces in filenames).
[deleted]
Re: Makefiles for web work
#44Just [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.
> Go and Rust projects hardly needed just
It depends on what you're producing as output.
One of my golang projects needs `-s -w -X '' -trimpath` along with separate GOOS and GOARCH depending on platform.
It is nice to have all that documented in a build file.
Re: Makefiles for web work
#45Earlier quoted context omitted.
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.
> Go and Rust projects hardly needed just It depends on what you're producing as output. One of my golang projects needs `-s -w -X '' -trimpath` along with separate GOOS and GOARCH depending on platform. It is nice to have all that documented in a build file.
Yep, agreed!
Re: Makefiles for web work
#46I tried this for a bit until I found out make couldn't deal with spaces in the file name. switched to rake (ruby), which had the advantage of not needing to write separate shell scripts.
Why do you have spaces in the filenames of your project in the first place? They require annoying escapes to work with essentially everywhere, notably including on the web. You have complete control over the filenames in your project... why are actively choosing to use a space character? I can see a better argument for wanting to use an apostrophe in a filename than a space character :(.
Because I wanted the title of my blog posts to match the file name, so I didn't have to remember which markdown file was which post.
Re: Makefiles for web work
#47It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job. (I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).
In our case we have most of the processes that are run by make tee their output into a project log directory. Then the make rules can use the log file itself as the dependency for the target. Works great in a lot of cases, and, you get the added benefit of being able to easily go back and observe previous process output and compare it across projects.
Re: Makefiles for web work
#48It's interesting, but I can't help but think that by the time you're adding `.PHONY` after most rules, you're not using the right tool for the job. (I generally find a small set of shell scripts work, or just three or four rules in the package.json file I can access with `npm run`).
The [Just] task runner can be what you want: it's simpler than Make, with less magic, but it allows to declare task dependencies.
[Just]: https://github.com/casey/just
Re: Makefiles for web work
#49>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.
126 ms is already well above the threshold of latency you can expect to notice when typing at a keyboard. By comparison, it'd almost be a long enough time to start caring as a TTFB. It really is a shockingly long time.
Re: Makefiles for web work
#50Earlier quoted context omitted.
I see `.PHONY` as a hack, `MAKEFLAGS += --no-builtin-rules` as a workaround, and many of the builtin functions as being difficult to use, read, and understand. A long string of nested replacements generating the sources for a task is a pain to read and maintain. What I want out of task runners nowadays is to run tasks . If I can't make a task without writing '.PHONY' - there's a problem with the task runner.
Meh. OK. Though almost always, "run tasks" implies some level of state. Are you tasks truly all idempotent and parallelizable? If not, maybe they should produce output and be tracked by dependencies? If so, then you probably have bugs in your "task runners" that will show up in weird ways. It's absolutely true that ".PHONY" looks like a hack; it was sort of meant to. In general you shouldn't be using it, except maybe…
> Though almost always, "run tasks" implies some level of state.
Yes! But isn't one of the major design principles of Make that the host filesystem is the container for the state? (iirc Make decides when to re-run rules based on when the timestamp on a target is older than the timestamp on an input file)