Show HN: Werk, a simple build tool and command runner
simonask.github.io
I made this for my personal workflow, but I'd love to get feedback from the community.
simonask.github.io
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!
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.
> 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.
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...
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?
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?
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.
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 ?)
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.