Someone recently had an issue using roc-wasm4, https://github.com/lukewilliamboswell/roc-wasm4/issues/25
I was wondering if anyone would be interested in helping update the platform use a later zig version, such as 0.12.0?
It's a tiny code base, so there shouldn't be much to upgrade. I think it might be limited to the build.zig
script.
Or maybe a better solution is to add a flake or similar to help people get set up on the correct version?
Ah, I started experimenting in this direction and even made some progress. But my zig knowledge (especially regarding its build system) is very limited, so it's moving very slowly
Yeah, I haven't looked at zig 0.12.0 much yet.
I’m game to take a look at this in the next few days unless someone else has time before I do.
Should be a good way to get more familiar with both Zig and platforms.
I have a draft PR open: https://github.com/lukewilliamboswell/roc-wasm4/pull/26
I feel like I've made a fair bit of progress, but I haven't fixed everything.
Lots to change, especially in glue.
That sounds like we need to update the builtins in Roc
Those glue files are vendored from the roc repository.
Yes, I just checked the roc builtins and they definitely will need to change.
Yeah, I don't understand much of how glue works but I could see that you were pulling them in from the compiler builtins.
Hmm. I guess we could update them here, check it's all good, and then it will be easy to copy back into the repository...
My only concern is that if there are any PR's in roc that modify builtins we might get out of sync. But I don't think there are any currently under way
I wasn't sure whether I should change the files in this repo or not. So I'm definitely ok with waiting if you'd prefer.
I've been thinking of cleaning up those files anyway and removing all the non-essential parts. there's a lot there that isn't needed for platform development.
Actually the best solution would be to update the files in https://github.com/lukewilliamboswell/roc-glue-code-gen and use a glue.roc script to generate the files in the roc-wasm4 platform.
We could maybe have two versions of the builtins in the package, both 0.11 and 0.12.
And we could remove all the non-essential parts and simplify it for platform developers
There's an example glue script and build script in https://github.com/lukewilliamboswell/roc-platform-template-zig/tree/main
I'm happy to help as I have time, if it means I get to learn the mysteries of platform development. As long as you don't mind some questions.
Awesome! :smiley: happy to answer all the questions (as best I can). Hopefully that will help others too, and might help us improve the docs for platform development
Did somebody do something about platform development in one of the meetups sometime in the past year?
Or perhaps was it a stream Brendan did?
I seem to recall that someone did a video session related to platform development, but I've slept since then :sweat_smile:
If that exists, I should watch it in case it answers some of my questions.
https://drive.google.com/file/d/1LHaGTKXWhP0N5VvbjkP5k2SazElzrG0D/view?usp=sharing&t=2439
Yeah that was me. I'm not happy with my presentation -- I was very tired and it shows. But this was the talk.
And here are the slides from my presentation 20230525-Roc-Platform-Development.pdf too
Nice! Thanks for digging that up!
I've been thinking I should include these somewhere more discoverable... but I'm not sure where that could live
Ok, so next steps are updating roc-glue-code-gen for Zig 0.12, and then we should be able to generate the files for roc-wasm4. Did I understand that correctly?
The idea behind that glue code gen package is that we can have one place for these glue files to live and then they are automatically generated by build scripts. That will make updates like this easier in future. Ofc, when we made roc-wasm4 we didn't have that, as I only just figured out how to put all this together and made those template repositories
Yeah, it might be easiest just to update in the roc-wasm4, and then once we know its good we can copy and paste into the package and change roc-wasm4 to use a build script to generate these glue files.
Ah, so the generated files wouldn't live in source control anymore for roc-wasm4?
Or would you still commit them?
I'm not 100%, but my understanding is that it is best not to commit auto generated files.
Yeah, that's my instinct as well. Just wanted to confirm I was following. So then the build.zig
in roc-wasm4 would run roc glue as part of the build, perhaps?
I like that you can just git clone
and your off and away, and theres always a script to regenerate them... but I guess it means if there are bug-fixes in the source that wont be reflected unless someone actually regenerates and commits the files
Or perhaps there would be a way to check whether generating glue is necessary? if the glue dir is empty, run roc glue
, else assume it's ok.
In the zig platform template I currently have a build.roc
which drives everything. I've kind of just settled on that as it feels nice to have all the platforms using roc as the "build" script. But it may make more sense for the zig build system to be in charge
I don't anticipate having any complaints about writing a build script in Roc vs Zig :grinning:
Would make the experience of developing a game using roc-wasm4 more, uh, roc-y?
Either way, sounds like there is plenty to do!
I'm not sure whether my changes to the builtins are good, because I'm running into another error. See my comment on the PR regarding the wasm build artifact. I may end up needing help on that one, though it is possible that I'll find the answer in the documentation somewhere on my next go. I'm guessing I'll have more time tomorrow evening.
Any assistance will be most appreciated. I try to just to a little bit here and there, and hopefully together we will be able to build something really nice over time
Your "little bit here and there" seems to be quite a bit relative to the Roc project!
Oh, this is the same issue I am currently stuck on with https://github.com/lukewilliamboswell/roc-platform-template-wasi
I haven't had a chance to thoroughly investigate though. I think we could keep it as a sharedLibrary for now if that still works?
Let me see, I think I changed it because I got an error about the target not supporting dynamic libs or something?
Brendan left a comment there which is why I suspected that I needed to use addExecutable
. But I really have no clue what I'm doing :sweat_smile:
I'm guessing we want sharedLibrary, would need to dive into wasm4 docs. The b.addExecutable
probably instructs zig to build for WASI, but I'm thinking we may not need all that for wasm4 game carts
Ah, ok. Because the cart is just a library that W4 links when you run it?
Or something like that?
Yeah, the wasm4 game engine loads the .wasm
file as a game cartidge
And a .wasm
file is basically a dynamic/shared library. The "exectuable" kind of wasm is basically WASI, and the zig compiler adds additional things so a runtime like wasmer, wasmtime etc will run these like normal programs with access to filesystem and other OS resources just using the zig std library.
Ok, I think that makes sense. WASM is simply a binary instruction format. WASI allows wasm instructions to interact with the system. But in the case of W4, we don’t need to interact with the system directly. The W4 runtime takes care of all that.
Hence, if we target WASI, the cart will be bloated with things we don’t need.
Yeah, I think so.
Ok, got it working with addExeutable
by referencing the zig template generated by w4. This should at least allow us to validate the changes to the builtin files.
Ah yeah, they changed to add executable in 0.12
Forget why it didn't work in 0.11
It seems the solution to my WASI problems and roc linking may be that we need to upgrade roc to 0.12. :grinning_face_with_smiling_eyes:
Thank you @Bryce Miller - zig 12 works well :smiley:
Last updated: Jul 06 2025 at 12:14 UTC