# Zig watch similar to cargo watch **URL:** \ **Category:** Help\ **Tags:** build-system\ **Created:** [June 18, 2024, 6:42pm UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780 "2024-06-18T18:42:57Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![huntrss](https://ziggit.dev/user_avatar/ziggit.dev/huntrss/32/6342_2.png) [@huntrss](https://ziggit.dev/u/huntrss)\ **Post date:** [June 18, 2024, 6:42pm UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/1 "2024-06-18T18:42:58Z")
Hi, Is there an existing zig module or some a zig build file template that adds functionality similar to what [cargo watch](https://github.com/watchexec/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](https://www.man7.org/linux/man-pages/man7/inotify.7.html) but I thought I could ask here first if someone does something similar. ---
**Author:** ![Calder-Ty](https://ziggit.dev/user_avatar/ziggit.dev/calder-ty/32/10237_2.png) [@Calder-Ty](https://ziggit.dev/u/Calder-Ty)\ **Post date:** [June 18, 2024, 8:29pm UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/2 "2024-06-18T20:29:45Z")
I’ve used [watchexec](https://github.com/watchexec/watchexec) to run commands on file change. `watchexec -e zig zig build` ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [June 18, 2024, 8:34pm UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/3 "2024-06-18T20:34:13Z")
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](https://github.com/ziglang/zig/issues/68) 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. ---
**Author:** ![huntrss](https://ziggit.dev/user_avatar/ziggit.dev/huntrss/32/6342_2.png) [@huntrss](https://ziggit.dev/u/huntrss)\ **Post date:** [June 18, 2024, 8:59pm UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/4 "2024-06-18T20:59:12Z")
Thanks, I try it out tomorrow ---
**Author:** ![Luke](https://ziggit.dev/letter_avatar_proxy/v4/letter/l/7ab992/32.png) [@Luke](https://ziggit.dev/u/Luke)\ **Post date:** [June 19, 2024, 7:54am UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/5 "2024-06-19T07:54:31Z")
If you are on a reasonably posix system, [entr](https://github.com/eradman/entr) is very simple and does the job. ---
**Author:** ![huntrss](https://ziggit.dev/user_avatar/ziggit.dev/huntrss/32/6342_2.png) [@huntrss](https://ziggit.dev/u/huntrss)\ **Post date:** [June 19, 2024, 8:00pm UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/6 "2024-06-19T20:00:40Z")
I use watchexec for now. ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [July 10, 2024, 10:32pm UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/7 "2024-07-10T22:32:45Z")
> > > \## Feature Explanation > > \`\`\` > --watch Continuously rebui…ld when source files are modified > --debounce \ 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 ---
**Author:** ![andrewrk](https://ziggit.dev/user_avatar/ziggit.dev/andrewrk/32/7011_2.png) [@andrewrk](https://ziggit.dev/u/andrewrk)\ **Post date:** [July 13, 2024, 2:19am UTC](https://ziggit.dev/t/zig-watch-similar-to-cargo-watch/4780/8 "2024-07-13T02:19:01Z")
Discussion continues at > [@Initial implementation of \`zig build --watch\` just landed in master branch](https://ziggit.dev/t/initial-implementation-of-zig-build-watch-just-landed-in-master-branch/5117): > > For those adventurous Zig users out there living on master branch, and who happen to use Linux, give the new --watch flag a try, and see if you like it. Windows and macOS support are close, just needs some OS-specific glue code to make it work. I’m fairly confident the abstractions that I made will hold up nicely when it comes to those file system APIs since it’s based on watching directories only. Contributions welcome! The way I see it, the end goal here is having incremental compilation +…