Show HN: Werk, a simple build tool and command runner(simonask.github.io)
simonask.github.io
Show HN: Werk, a simple build tool and command runner
https://simonask.github.io/introducing-werk/
I made this for my personal workflow, but I'd love to get feedback from the community.
13 comments
We've been using Taskfile, which is fantastic and super understandable, but it's only a task-runner and as such wouldn't meet OP's needs. I hated `just` and did not find it at all intuitive.
Only problem I have with the article is saying that Ruby doesn't work on Windows is just categorically false. It's one of the easiest languages to install and use on Windows, even easier than C# and Java, and I'm a Java/Kotlin dev, so that's saying something. It's literally just a single exe/msi installer.
But you wouldn't want to be using Rake anyway, it's not really that good, and is only useful if you're working in an environment where you don't want to install anything and you hate Make. Then Ruby is very often installed by default with Rake and so you get a 'free' build tool. Rake was good 10 years ago, but not so much anymore.
Anyway, if you needed a specific kind of tool and built it then all the power to you. Can't blame you for not wanting to use the other options!
Only problem I have with the article is saying that Ruby doesn't work on Windows is just categorically false. It's one of the easiest languages to install and use on Windows, even easier than C# and Java, and I'm a Java/Kotlin dev, so that's saying something. It's literally just a single exe/msi installer.
But you wouldn't want to be using Rake anyway, it's not really that good, and is only useful if you're working in an environment where you don't want to install anything and you hate Make. Then Ruby is very often installed by default with Rake and so you get a 'free' build tool. Rake was good 10 years ago, but not so much anymore.
Anyway, if you needed a specific kind of tool and built it then all the power to you. Can't blame you for not wanting to use the other options!
> It's literally just a single exe/msi installer.
And so is .NET. Just install SDK from a single exe (or, on macOS, do 'brew install dotnet'), open VSCode, maybe get the C# extension. That's it. dotnet run, dotnet build, etc.
For scripting, there is 'dotnet fsi' for F# interactive. And you can also compile F# scripts directly into native executables with community tooling if you wish to make them full standalone programs.
And so is .NET. Just install SDK from a single exe (or, on macOS, do 'brew install dotnet'), open VSCode, maybe get the C# extension. That's it. dotnet run, dotnet build, etc.
For scripting, there is 'dotnet fsi' for F# interactive. And you can also compile F# scripts directly into native executables with community tooling if you wish to make them full standalone programs.
What in particular tips the balance to Taskfile compared to just(file)? With one of my clients I’ve been using just for months, so I’m curious. Thanks!
I wish you success with this! I really was surprised to see that there isn’t a modern make replacement that actually does what make does, and does it well: build /compile things with a notion of inputs and outputs and out-of-date checks. Most appear to be “just” command runners. That’s a very useful thing to have, but it’s not really a make replacement.
Then again, many “build tools” do get very large and unwieldy eventually, so maybe it’s more a case of the good make replacements simply getting too much traction…
what about meson?
OP wanted speed. You don't get that with Meson.
that's not how meson describes itself:
> Meson is an open source build system meant to be both extremely fast, and, even more importantly, as user friendly as possible.
now I've never used it, so I can't directly defend that claim. I have heard good things about meson though and it would seem strange to me such a headline would make sense on a project that I also hear good things about.
> Meson is an open source build system meant to be both extremely fast, and, even more importantly, as user friendly as possible.
now I've never used it, so I can't directly defend that claim. I have heard good things about meson though and it would seem strange to me such a headline would make sense on a project that I also hear good things about.
> Why a new language?
In my opinion, Starlark (in rust, Apache 2: <https://github.com/facebook/starlark-rust/blob/v0.13.0/LICEN...>) is the way since it is designed for sandboxed environments and also (AIUI) was initially designed to support Bazel, a build tool
Now, I'm totally on board that people can hate on whitespace sensitive languages, but if my choice was "make my own language that no one has ever heard of" or "delete the Python hater's emails" ...
It also would mean that you could tag your Werkfile in .gitattributes with linguist annotations[1] and they'd syntax highlight, which isn't the case with your own language https://github.com/simonask/werk/blob/5990c8a9536a1a76c3da59...
1: https://github.com/github-linguist/linguist/blob/v9.0.0/docs...
In my opinion, Starlark (in rust, Apache 2: <https://github.com/facebook/starlark-rust/blob/v0.13.0/LICEN...>) is the way since it is designed for sandboxed environments and also (AIUI) was initially designed to support Bazel, a build tool
Now, I'm totally on board that people can hate on whitespace sensitive languages, but if my choice was "make my own language that no one has ever heard of" or "delete the Python hater's emails" ...
It also would mean that you could tag your Werkfile in .gitattributes with linguist annotations[1] and they'd syntax highlight, which isn't the case with your own language https://github.com/simonask/werk/blob/5990c8a9536a1a76c3da59...
1: https://github.com/github-linguist/linguist/blob/v9.0.0/docs...
This seems pretty much in line with my ideals for a make replacement, which is a project I have been thinking about starting for ages. The only major use-cases I have that don't seem to be covered are "tasks" in werk parlance that only run given changes in some "from" files, and just-once tasks. For both of these in Make I use empty files as targets, e.g. `make/foo`, which I `touch` at the end of the recipes.
An example of a just-once task might be running some setup script on dev machines when setting up a work environment. An example of a task with prereqs might be running a nix command to source things into the local environment whenever a `shell.nix` or other file changes.
I also wasn't able to immediately find documentation on what the available config options are (referenced in the language documentation). Is it possible to set a shell to use for run statements?
An example of a just-once task might be running some setup script on dev machines when setting up a work environment. An example of a task with prereqs might be running a nix command to source things into the local environment whenever a `shell.nix` or other file changes.
I also wasn't able to immediately find documentation on what the available config options are (referenced in the language documentation). Is it possible to set a shell to use for run statements?
This looks very cool to me, and I might start using it for my projects. Anything I can use to get away from make and, especially, CMake, is a massive win in my book.
I've used mk in the past, but asking users to install Plan 9 from User Space is a big ask :). A rust program they can just build with cargo feels a lot better.
Questions:
* is there a way to pass arguments, such as CC etc. to werk. will config or let skip past the first assignment if there is an environment variable defined with the same name? or how do i get my config to werk without editing the werkfile
* does the depfile rule get called if the depfile already exists? if so, what are the performance implications of this? if not, what happens when I include a new header in a file and the dependencies change?
I've used mk in the past, but asking users to install Plan 9 from User Space is a big ask :). A rust program they can just build with cargo feels a lot better.
Questions:
* is there a way to pass arguments, such as CC etc. to werk. will config or let skip past the first assignment if there is an environment variable defined with the same name? or how do i get my config to werk without editing the werkfile
* does the depfile rule get called if the depfile already exists? if so, what are the performance implications of this? if not, what happens when I include a new header in a file and the dependencies change?
[deleted]
Man, we've seen so many replacements for make over the past two decades. Make is gonna be a really, really hard tool to unseat: it's small, it's reliable, it's pretty cross-platform, it solves a narrowly-defined problem well, and it seems like 95% of what people want is a slightly different syntax or interface.
Meanwhile, I am never going to abandon a working tool that does what it says on the tin for something users have to go out of their way to install without a really good reason. .PHONY hasn't bothered me in decades. It's a reasonable hack, imo.
Make hits a really, really sweet spot of addressing a hard problem with a simple, understandable interface. It's not too large, it's not too small, it just does one thing really, really well.
Meanwhile, I am never going to abandon a working tool that does what it says on the tin for something users have to go out of their way to install without a really good reason. .PHONY hasn't bothered me in decades. It's a reasonable hack, imo.
Make hits a really, really sweet spot of addressing a hard problem with a simple, understandable interface. It's not too large, it's not too small, it just does one thing really, really well.
Getting make to work on Windows (a hard requirement from OP) the same way as on Linux is basically impossible.
If you only live in the Linux/Unix world than make is more than enough, I agree.
The features/goals sound great, thank you!
These stood out for me as possibly limiting/offputting for wide general use:
- Not being able to generate files in the same directories as input files, or in multiple output directories
- Not being able to provide command line arguments to tasks, as in just
- The mandatory curly braces syntax (and to a lesser extent, smaller verbosities like mandatory `let` keyword). These seem like conveniences for the implementor rather than ideal UX.
The doc for `build` didn't seem quite complete about what can go in there (one of the examples uses a build keyword inside a build recipe ?)
These stood out for me as possibly limiting/offputting for wide general use:
- Not being able to generate files in the same directories as input files, or in multiple output directories
- Not being able to provide command line arguments to tasks, as in just
- The mandatory curly braces syntax (and to a lesser extent, smaller verbosities like mandatory `let` keyword). These seem like conveniences for the implementor rather than ideal UX.
The doc for `build` didn't seem quite complete about what can go in there (one of the examples uses a build keyword inside a build recipe ?)
I see why the author did this, building a video game with all of its resources (source code, shaders, assets, docs etc.) is actually very complicated.
But then I might ask why all of it needs to be build all of the time? Why not make dedicated build steps for every sort of resource and maintain a global build script for all? Doing it the KISS way seems more practical to me than inventing a completely new tool. This is my approach to build software for 20 years now, and it never failed me.
But then I might ask why all of it needs to be build all of the time? Why not make dedicated build steps for every sort of resource and maintain a global build script for all? Doing it the KISS way seems more practical to me than inventing a completely new tool. This is my approach to build software for 20 years now, and it never failed me.
This looks nice. A watch mechanism built in to continuously monitor file changes and kick off the make/run process would be fantastic.
Really digging the ideas here - thanks for building this!
kudos bro, website palette is juicy. Seems useful!