Zig watch similar to cargo watch

huntrss · June 18, 2024, 6:42pm

Hi,
Is there an existing zig module or some a zig build file template that adds functionality similar to what cargo watch does?
What cargo watch (and other similar tools for other languages) does is it executes (example given “zig build”) a cargo command whenever a file in the project’s source tree changes.
My use case is, that I want to create a simple game for fun, as a Web Assembly module, and I want to rebuild my project as WASM module whenever one of my source code files changes so that I can hot reload my game whenever I make a change. (I need to implement some basic hot reloading into my game logic as well as maybe manually refreshing the browser).
I guess I can hack something together using inotify but I thought I could ask here first if someone does something similar.

Calder-Ty · June 18, 2024, 8:29pm

I’ve used watchexec to run commands on file change.
watchexec -e zig zig build

andrewrk · June 18, 2024, 8:34pm

Not yet but that’s an idea that I’ve had in mind for a while now.

The good news is that most of the framework is already there; the compiler already speaks a protocol to communicate semantically information to the parent process, and the build runner acts as a multiplexer. The cache system already has a complete list of files that when changed indicate a rebuild is needed. I’ve been slowly building up to this feature all this time.

It would also be neat to integrate this with user applications - for example, zig build run could spawn the application with a special pipe open that communicates information about rebuilds. For example, if your application is a web server, it could poll the pipe to find out when a rebuild occurs, and find out which installation files in particular have been updated, reload them in memory, and maybe even send a message to connected clients, telling them to refresh certain assets, or maybe the entire page.

Related: hot code swapping · Issue #68 · ziglang/zig · GitHub

I don’t want only a cool hot code swapping demo - I want it to be fully integrated with the build system, and practically useful for many different kinds of projects.

huntrss · June 18, 2024, 8:59pm

Thanks, I try it out tomorrow

Luke · June 19, 2024, 7:54am

If you are on a reasonably posix system, entr is very simple and does the job.

huntrss · June 19, 2024, 8:00pm

I use watchexec for now.

andrewrk · July 10, 2024, 10:32pm

github.com/ziglang/zig

introduce file system watching features to the zig build system

ziglang:master ← ziglang:watch

opened 10:32PM - 10 Jul 24 UTC

andrewrk

+1183 -346

## Feature Explanation ``` --watch Continuously rebui…ld when source files are modified --debounce <ms> Delay before rebuilding after changed file detected ``` Uses the build system's perfect knowledge of all file system inputs to the pipeline to keep the build runner alive after completion, watching the minimal number of directories in order to trigger re-running only the dirty steps from the graph. Default debounce time is 50ms but this is configurable. It helps prevent wasted rebuilds when source files are changed in rapid succession, for example when saving with vim it does not do an atomic rename into place but actually deletes the destination file before writing it again, causing a brief period of invalid state, which would cause a build failure without debouncing (it would be followed by a successful build, but it's annoying to experience the temporary build failure regardless). The purpose of this feature is to reduce latency between editing and debugging in the development cycle. In large projects, the cache system must call `fstat` on a large number of files even when it is a cache hit. File system watching allows more efficient detection of stale pipeline steps. Mainly this is motivated by incremental compilation landing soon, so that we can keep the compiler running and responding to source code changes as fast as possible. In this case, also keeping the rest of the build pipeline up-to-date is table stakes. This also paves the road towards #68. A `Run` step combined with `--watch` connects file system updates directly to new code inside an already-running executable. It takes steps closer to more advanced use cases as well: * IDE plugin running `zig build --watch --listen=-` as a child process, speaking a compiler protocol (#615) to learn about type information, perform refactors, request rebuilds, receive errors, etc. The protocol will multiplex between an arbitrary number of `Compile` steps, each with a running instance of the compiler. * An application, compiled in debug mode, speaking the build runner protocol, able to poll on a file descriptor and learn when a hot swap is available, requesting it when it is convenient, or learning about new installed asset updates occurring. ## Merge Checklist * integrate with more build steps * Compile.zig * Run.zig * TranslateC.zig * Windows implementation * macOS implementation * other posix implementation * make --watch handled special with Compile Step, keep compiler running ## Follow-Up Work * give Run Step a special fd to communicate with build runner * add `--listen=-` and build runner protocol * make build runner detect modifications to itself and reexec itself * audit memory allocations - use single-threaded arena for configure phase - use thread-safe GPA for make phase and fix leaks - use temporary arena for internal make() allocations

andrewrk · July 13, 2024, 2:19am

Discussion continues at