[HN Gopher] Show HN: Werk, a simple build tool and command runner
       ___________________________________________________________________
        
       Show HN: Werk, a simple build tool and command runner
        
       I made this for my personal workflow, but I'd love to get feedback
       from the community.
        
       Author : simonask
       Score  : 66 points
       Date   : 2025-01-12 11:40 UTC (1 days ago)
        
 (HTM) web link (simonask.github.io)
 (TXT) w3m dump (simonask.github.io)
        
       | o_1 wrote:
       | kudos bro, website palette is juicy. Seems useful!
        
       | serbuvlad wrote:
       | 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?
        
       | kkukshtel wrote:
       | Really digging the ideas here - thanks for building this!
        
       | mplanchard wrote:
       | 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?
        
       | mdaniel wrote:
       | > 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...
        
       | snowe2010 wrote:
       | 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!
        
         | neonsunset wrote:
         | > 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.
        
       | TheTaytay wrote:
       | 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...
        
       | PittleyDunkin wrote:
       | 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.
        
       | ww520 wrote:
       | This looks nice. A watch mechanism built in to continuously
       | monitor file changes and kick off the make/run process would be
       | fantastic.
        
       ___________________________________________________________________
       (page generated 2025-01-13 23:02 UTC)