Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taskfile: A Modern Alternative to Makefile

cloudnativeengineer.substack.com

Post reply on HN
Print view View original

201–210 of 223 posts

Re: Taskfile: A Modern Alternative to Makefile

#201

Post by inopinatus »

datastack wrote: post #30
crabbone wrote: post #9

I have coworkers who use this. They tried to make me use this too. I failed to see the point. It offers no benefits of a build system, no benefits of existing automation tools, comes with "bespoke" syntax and requires installing an extra program to run it. I have never tested it enough to discover things it does wrong, but given how new and not exactly popular this tool is, I bet there are lots of things it doesn't d…

some tasks a developer might need to do besides just building the application: - copying a database from production to local for bug reproduction/fixes - inserting seed-data into the local database - creating a migration after changing records - applying the migration - rolling back the migration - running a tool to copy configuration from a keyvault - running the end to end tests - generate certificates - set up an…

> stuff all of them in a task runner with simple aliases

$ mkdir bin

> easily be able to do these things, without asking help each time

$ ls bin

> generate certificates

$ bin/mkcert.sh

What you didn't need: yet another tool and config syntax as a dumping bucket for your one-liners and command aliases.

Re: Taskfile: A Modern Alternative to Makefile

#203

Post by [deleted] »

tjoff wrote: post #44
amno wrote: post #21

I don't understand this argument: "it's 47 years old" as a bad thing. If something has been around that long, does it not mean it is proof tested? The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension l…

That is not the argument though. The argument is: After being unhappy with Makefile for years now As to why being unhappy is probably not because it haven't been proof tested. I get your sentiment but feel the remark is out of place. I thought the rationale for picking other tools was straightforward and motivated. Though the simplicity of make has been lost and I'm not sure the overhead is worth it. I wouldn't want…

[deleted]

Re: Taskfile: A Modern Alternative to Makefile

#204

Post by inopinatus »

tjoff wrote: post #44
amno wrote: post #21

I don't understand this argument: "it's 47 years old" as a bad thing. If something has been around that long, does it not mean it is proof tested? The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension l…

That is not the argument though. The argument is: After being unhappy with Makefile for years now As to why being unhappy is probably not because it haven't been proof tested. I get your sentiment but feel the remark is out of place. I thought the rationale for picking other tools was straightforward and motivated. Though the simplicity of make has been lost and I'm not sure the overhead is worth it. I wouldn't want…

Software build has essential complexity. Dealing with peculiarities in config syntax is a mere drop in the vast lake of unhappiness wept from having to deal with build at all. It's the tools that are salient, so folks may perceive that it's the tools at fault and must be reworked, but it isn't really: complexity in build tools is an emergent property of the domain, and any sufficiently developed reinvention will asymptotically correspond to makefiles.

Re: Taskfile: A Modern Alternative to Makefile

#205

Post by rewmie »

IceSentry wrote: post #192
rewmie wrote: post #36

Earlier quoted context omitted.

> UNIX might be standard but it doesn't make it cross platform. You might not like it but a lot of people develop on windows. I fail to understand what point you tried to make. There are already plenty of Make implementations for Windows. If you think that installing a third party tool like Task is ok, I don't see how doing the same with a Make implementation would exclude it as a valid alternative.

I don't think using Task is better either. I was just replying to OP saying to just use unix tools. Unix tools aren't cross platform so they aren't a good build tool either.

> Unix tools aren't cross platform (...)

I just pointed out there are Make implementations for Windows.

And I'm not even mentioning WSL or MinGW.

I don't know what else to say.

Re: Taskfile: A Modern Alternative to Makefile

#206

Post by deviantintegral »

We’ve been using Task for our (Drupal) web projects for a few years now and are really pleased with it.

Why not Make? We actually used that on a few projects previously, but found it challenging to use with both our teams and with typical tools used in the PHP and JavaScript stack.

1. Most of our newer hires have never used Make before, or anything like it. It seems to have fallen out of many curriculums in favour of other build tools, presumably due to decreasing focus on C / C++ in fundamental computer science classes. The idea that a build tool is inherently files based is a completely foreign concept. 2. File-based dependency tracking being the exception, and not the rule, simply works better with the majority of the types of tasks we run. Those include building docker containers, pulling down CMS databases for local development, and running CLI tasks like database migrations. 3. For those tasks that can be tracked with files, Task supports both timestamps and hashes.

One big win of Task over other tools is that it ships it’s own built-in sh shell. If you have tasks that run on a host and not in a container, it significantly reduces your host dependencies. Being a typical single-binary go app makes deployments easy too.

I’ll also say the maintainers have been very responsive to our few bug reports and feature requests, and responsive to our contributions too.

The worst part is yes, it’s another YAML DSL to learn. And personally, I wish Make had gained more traction in the web and docker world. But given all of the above, the trade offs of switching to Task have been worth it for us.

Re: Taskfile: A Modern Alternative to Makefile

#207

Post by thiht »

inopinatus wrote: post #198
thiht wrote: post #105

Earlier quoted context omitted.

> 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 unders…

Keep digging this hole and you will just reinvent make, only worse. It's like Greenspun's tenth rule, only for build tools.

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

Re: Taskfile: A Modern Alternative to Makefile

#208

Post by booi »

EuAndreh wrote: post #176
taspeotis wrote: post #51

Earlier quoted context omitted.

Can you use spaces in filenames with GNU make yet? Seems like a 47yo vestige when spaces in filenames weren’t really a thing…

In GNU make? Actually, yes: $ cat Makefile a\ file: ; echo 123 > '$@' $ make echo 123 > 'a file' $ cat a\ file 123

AFAIK this does work but it’s a limited workaround. Make in general just does not support file names with spaces well.

http://savannah.gnu.org/bugs/?712

That being said… In projects I just avoid filenames with spaces in general

Re: Taskfile: A Modern Alternative to Makefile

#209

Post by blacklion »

thiht wrote: post #90
trabant00 wrote: post #26

Earlier quoted context omitted.

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?

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…

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!

Re: Taskfile: A Modern Alternative to Makefile

#210

Post by amno »

ModernMech wrote: post #110
amno wrote: post #21

I don't understand this argument: "it's 47 years old" as a bad thing. If something has been around that long, does it not mean it is proof tested? The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension l…

It’s proof tested yes. But it still falls over if you put in a space versus a tab, and the error message is cryptic and frustrating to beginners. Make is such a huge impediment to C adoption, long time users have no idea. Even the fact makefiles have no extension is confusing to beginners. Everything about it screams outdated, idiosyncratic computing artifact and students pick up on that.

> But it still falls over if you put in a space versus a tab

It fails only in a certain part of the script where tab is part of the syntax. It is like saying Python language fails if I add a wrong number of spaces, or replace a space with a tab, since white spaces are part of the Python syntax.

> Even the fact makefiles have no extension is confusing

How is that confusing, the entire filename (makefile) is "the extension" :-)

Put .mk at the end of the file name if that makes you happy and less "outdated" and "idiosyncratic". C/C++ does not require extension either, it is just a convention. Ever seen , , etc?

Post reply on HN