10 ms·
> due to a poor format (YAML). That's just your opinion. I'll take YAML whitespaces over Makefile whitespaces any day. > Compare with Makefile that does exact
by thiht 2y ago
> due to a poor format (YAML).
That's just your opinion. I'll take YAML whitespaces over Makefile whitespaces any day.
> Compare with Makefile that does exactly the same thing
Good example in favor of Task, I prefer the explicitness :) Especially when the file starts to get big. You forgot the .PHONY by the way, I hope for you there's no build/ or assets/ folder where your Makefile is.
For a more useful comparison, with actual source dependencies and build target:
Makefile:
GO_FILES = $(shell find . -type f -name '*.go')
./myapp: $(GO_FILES)
go build -trimpath -o $@
.PHONY: build
build: ./myapp
Taskfile:
tasks:
build:
cmds:
- go build -trimpath -o ./myapp
sources:
- '**/*.go'
generates:
- ./myapp
Makefiles are incredibly terse, but that's not an advantage. I read my code more than I write it, so I favor explicitness .
- lelanthran 2y ago> For a more useful comparison, with actual source dependencies and build target: Makefile: GO_FILES = $(shell find . -type f -name '*.go') ./myapp: $(GO_FILES) go build -trimpath -o $@ .PHONY: build build: ./myapp Taskfile: tasks: build: cmds: - go build -trimpath -o ./myapp sources: - '\*/*.go' generates: - ./myapp Even in this example, what is PHONY needed for? GO_FILES = $(shell find . -type f -name '*.go') ./myapp: $(GO_FILES) go build -trimpath -o $@ Honestly, it's still simpler to read. > Makefiles are incredibly terse, but that's not an advantage. Brevity is not why I prefer Makefile syntax over YAML, readability is. The minute you start trying to do anything large in a YAML definition you're going to need special editor help to keep track of indentation, and even with that, a large tree is still going to be lost off-screen because the context of any node in the tree depends on seeing the lines immediately above. With Makefiles, any node in the tree has immediate context on the same line (the dependencies) which makes it very readable to me. I really prefer: target: dep1 dep2 dep3 dep4 compared to: tasks: dep3: cmds: - ... sources: - ... generates: - ... dep2: cmds: - ... sources: - ... generates: - ... dep1: cmds: - ... sources: - ... generates: - ... target: cmds: - ... sources: - ... generates: - ...