4 ms·

Because Make is too stable and well documented, because it's just one tool and not 3, because it isn't written in Go and because you don't have to scratch you h

Because Make is too stable and well documented, because it's just one tool and not 3, because it isn't written in Go and because you don't have to scratch you head at another YAML hell. Because 47 years of proven track record is nothing compared to "modern". Need I go on?

thiht 3y ago
If you think there’s nothing to fix with make, you’re severely mistaken. The differences between GNU Make and BSD Make are for me a big reason to be extra careful when using it. Make also relies a lot on cleverness so it comes with lots of idiosyncrasies (like having to add .PHONY to all the targets not representing files, which in itself proves Make was not thought to be used like we use it). Some basic conventions we use today are also hard to do correctly with a Makefile (using dotenv files for example) I used Task on a new project and the explicitness of it all was a breath of fresh air. I mean which is clearer between: BINARY = ./foo GO_FILES = $(shell find . -type f -name '*.go') # Rebuild BINARY only if GO_FILES have been modified $(BINARY): $(GO_FILES) go build -o $@ .PHONY: build build: $(BINARY) and env: BINARY: ./foo tasks: build: cmds: - go build -o $BINARY sources: - **/*.go generates: - $BINARY ?
- morelisp 3y ago
  What if you use `embed`? Why rebuild the binary if you've only touched test files? Make at least theoretically gives you tools to deal with these (but between Make and Go they're quite hard to use), but Task gives you no chance.
  - thiht 3y ago
    > What if you use `embed` You can add the embedded files to the "sources" list, no issues > Why rebuild the binary if you've only touched test files Yep, this is a thing not currently supported by Task, but they're considering extended globing iirc (with negation, like in gitignores). I think you could do something like that though: env: SOURCES: sh: find . -name *.go | grep -v _test.go kinda ugly, but easy to understand
    - inopinatus 3y ago
      Keep digging this hole and you will just reinvent make, only worse. It's like Greenspun's tenth rule, only for build tools.
      - thiht 3y ago
        I don’t see how this is worse than Make? This just shows that Taskfiles offers nicer syntax for some cases, but let’s you degrade to… something that looks just like Make actually, a variable initialized from a shell call
- inopinatus 3y ago
  > which is clearer (..) ? the makefile
  - thiht 3y ago
    In bad faith, yeah probably. $@, .PHONY, and the implicit target/dependency syntax is clever, terse, but NOT clear.
    - deleted 3y ago
      [deleted]
    - photonthug 3y ago
      It might be good to take a step back, and realize that the tool which is most "clear" is almost always the one which the user is most familiar with. It doesn't follow that the "clear" tool is actually more simple or more expressive. To find out which tool is more simple, we could just count core concepts or use docs-length as a proxy. But 50 years of makefile's will muddy the water here.. is it super complicated or just well-documented? At minimum, when you reach for makefile then you know the concepts it brings are stable if complicated, and the tool is available by default almost everywhere, and the tool-versioning is almost totally safe to ignore. Looking at taskfile, I don't know the schema for the config-yaml, and more importantly I have no real confidence it's stable over time. Worrying about that sort of thing for project libs is enough work, so people don't want this kind of trouble in their build system. I also know taskfile isn't available by default until I install it. Build-system yak-shaving mostly comes down to the same stuff. A group of people who don't want to learn tools try to convince everyone to learn some different tools, failing to realize that most of us are lazy in the same ways. Don't want to learn makefile tips and tricks? No one does really, but no one cares about taskfile tips and tricks either. Given the basic equivalence between these two situations.. there's definitely some wisdom here in preferring the standard rather than the startup.
    - deleted 3y ago
      [deleted]
    - deleted 3y ago
      [deleted]
- dwheeler 3y ago
  If your needs aren't trivial, just use GNU make if you're using make.
- blacklion 3y ago
  But.... It is not build... It is running one binary one time, without any inter-dependencies. This binary (go in case of golang and cargo in case of Rust) IS build tool in these cases. Looking at your example I think I understood why there is two schools for thoughts about this (and similar ones): because different ecosystems (go/rust vs C/C++/ObjC, mostly in these days, but also Fortran, etc) have completely different build needs. Golang and Rust (and node.js, AFAIK) almost doesn't need external build tool, as they have their own (go, cargo, npm). It is very easy to make receipt for such build in any, even very limited, DSL, with any "task running" software. On the other hand, how will Taskfile look for complex C/C++ project? You want separate on-demand compilation of each source file separately ("${CC} ${ALL-SOURCES}" is baaaaad idea), you need dependency extraction (ugly part of any Makefile, I admit, but receipts are well-known), you need linking, you often need some resource processing, or yacc/bison generation. I don't think, Task file with all these features will be less ugly than typical Makefile. And many tricks are non-existing for Taskfile (and it is not clear, are they possible at all without extending DSL), and well-known for Makefiles. This difference leads to polar views on such software. Thank you for example!

thiht 3y ago

If you think there’s nothing to fix with make, you’re severely mistaken. The differences between GNU Make and BSD Make are for me a big reason to be extra careful when using it. Make also relies a lot on cleverness so it comes with lots of idiosyncrasies (like having to add .PHONY to all the targets not representing files, which in itself proves Make was not thought to be used like we use it). Some basic conventions we use today are also hard to do correctly with a Makefile (using dotenv files for example) I used Task on a new project and the explicitness of it all was a breath of fresh air. I mean which is clearer between: BINARY = ./foo GO_FILES = $(shell find . -type f -name '*.go') # Rebuild BINARY only if GO_FILES have been modified $(BINARY): $(GO_FILES) go build -o $@ .PHONY: build build: $(BINARY) and env: BINARY: ./foo tasks: build: cmds: - go build -o $BINARY sources: - **/*.go generates: - $BINARY ?

morelisp 3y ago
What if you use `embed`? Why rebuild the binary if you've only touched test files? Make at least theoretically gives you tools to deal with these (but between Make and Go they're quite hard to use), but Task gives you no chance.
- thiht 3y ago
  > What if you use `embed` You can add the embedded files to the "sources" list, no issues > Why rebuild the binary if you've only touched test files Yep, this is a thing not currently supported by Task, but they're considering extended globing iirc (with negation, like in gitignores). I think you could do something like that though: env: SOURCES: sh: find . -name *.go | grep -v _test.go kinda ugly, but easy to understand
  - inopinatus 3y ago
    Keep digging this hole and you will just reinvent make, only worse. It's like Greenspun's tenth rule, only for build tools.
    - thiht 3y ago
      I don’t see how this is worse than Make? This just shows that Taskfiles offers nicer syntax for some cases, but let’s you degrade to… something that looks just like Make actually, a variable initialized from a shell call
inopinatus 3y ago
> which is clearer (..) ? the makefile
- thiht 3y ago
  In bad faith, yeah probably. $@, .PHONY, and the implicit target/dependency syntax is clever, terse, but NOT clear.
  - deleted 3y ago
    [deleted]
  - photonthug 3y ago
    It might be good to take a step back, and realize that the tool which is most "clear" is almost always the one which the user is most familiar with. It doesn't follow that the "clear" tool is actually more simple or more expressive. To find out which tool is more simple, we could just count core concepts or use docs-length as a proxy. But 50 years of makefile's will muddy the water here.. is it super complicated or just well-documented? At minimum, when you reach for makefile then you know the concepts it brings are stable if complicated, and the tool is available by default almost everywhere, and the tool-versioning is almost totally safe to ignore. Looking at taskfile, I don't know the schema for the config-yaml, and more importantly I have no real confidence it's stable over time. Worrying about that sort of thing for project libs is enough work, so people don't want this kind of trouble in their build system. I also know taskfile isn't available by default until I install it. Build-system yak-shaving mostly comes down to the same stuff. A group of people who don't want to learn tools try to convince everyone to learn some different tools, failing to realize that most of us are lazy in the same ways. Don't want to learn makefile tips and tricks? No one does really, but no one cares about taskfile tips and tricks either. Given the basic equivalence between these two situations.. there's definitely some wisdom here in preferring the standard rather than the startup.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
dwheeler 3y ago
If your needs aren't trivial, just use GNU make if you're using make.
blacklion 3y ago
But.... It is not build... It is running one binary one time, without any inter-dependencies. This binary (go in case of golang and cargo in case of Rust) IS build tool in these cases. Looking at your example I think I understood why there is two schools for thoughts about this (and similar ones): because different ecosystems (go/rust vs C/C++/ObjC, mostly in these days, but also Fortran, etc) have completely different build needs. Golang and Rust (and node.js, AFAIK) almost doesn't need external build tool, as they have their own (go, cargo, npm). It is very easy to make receipt for such build in any, even very limited, DSL, with any "task running" software. On the other hand, how will Taskfile look for complex C/C++ project? You want separate on-demand compilation of each source file separately ("${CC} ${ALL-SOURCES}" is baaaaad idea), you need dependency extraction (ugly part of any Makefile, I admit, but receipts are well-known), you need linking, you often need some resource processing, or yacc/bison generation. I don't think, Task file with all these features will be less ugly than typical Makefile. And many tricks are non-existing for Taskfile (and it is not clear, are they possible at all without extending DSL), and well-known for Makefiles. This difference leads to polar views on such software. Thank you for example!