Currently, whenever the Roc compiler compiles a Zig host, it looks for the glue.zig
package in the compiler builtin's source code folder to link into the final binary. Since we want glue plugins to output a Roc std library package along with the customized glue (like what Rust glue does today), I imagine this behavior can be removed in favor of that?
@Luke Boswell
Yeah it's gone in the llvm upgrade branch. We have talked about a roc_std like zig package, but havent made that yet.
First step is to land the zig and llvm upgrade.
So for zig 0.13.0 etc you can make a package and then use a .zig.zon file.
Actually, you probably need this package for your work? Even something minimal would be helpful right?
Maybe it's worth making a branch off from the llvm upgrade one, and starting on this zig package using zig 13.
Luke Boswell said:
Actually, you probably need this package for your work? Even something minimal would be helpful right?
Yeah exactly!
I'm a bit rusty with git still, would it be possible to merge the changes from the llvm-upgrade
branch into my fork's zig-glue
branch?
Yes, locally in the terminal, while you're on the zig-glue branch, execute git fetch
followed by git pull origin upgrade-llvm-zig
If it just had RocResult, RocStr, and RocList would that be enough?
I might he able to scrape something together... but not super confident in the refcounting side of things or small strings.
Oh that's okay! I was planning on adapting the builtins into a proper roc_std, like this comment in glue.zig
suggests:
// This is a glue package that just re-exports other libs useful for zig hosts.
// Long term, a slimmed down version of these libraries without all of the roc builtins should be create via `roc glue`.
// We also should make RocList use comptime types in order to make it nice to use in zig.
pub const dec = @import("dec.zig");
pub const list = @import("list.zig");
pub const str = @import("str.zig");
Since all the functionality's already there, cleaning it up into a roc_std
for platform use sounds doable for me. I just wanted to confirm that I could start replacing glue.zig
with it, or if there was a reason it still needed to be there!
Anton said:
Yes, locally in the terminal, while you're on the zig-glue branch, execute
git fetch
followed bygit pull origin upgrade-llvm-zig
thanks! I'll try that
$ git pull origin upgrade-llvm-zig
fatal: couldn't find remote ref upgrade-llvm-zig
I'm guessing it didn't work because I'm on a fork of the repo? @Anton
Luke Boswell said:
If it just had RocResult, RocStr, and RocList would that be enough?
I might he able to scrape something together... but not super confident in the refcounting side of things or small strings.
Would it be possible to change RocStr to use a given allocator? The current implementation uses roc_alloc implicit. This is not a good style for a zig package.
If you want, I can help you with the implementation. Since I wrote the Go implementation, I think I know all the tweaks with Str and List
Oskar Hahn said:
Would it be possible to change RocStr to use a given allocator? The current implementation uses roc_alloc implicit. This is not a good style for a zig package.
I believe it has to use roc_alloc
, because Roc would need to be able to free any values passed to it
Thanks for the offer! I'll want to try it myself first (I'm doing this for a school internship and would like to be able to show that I was able to do this!), I'll let you know if I run into any issues! :)
I'm guessing it didn't work because I'm on a fork of the repo? Anton
Riiight, this should do it:
steps
@Oskar Hahn left some helpful comments in Issues https://github.com/lukewilliamboswell/roc-platform-template-zig/issues for the zig template.
Thinking about this more, it might be easiest to make the package in that repo just as a starting point (until llvm upgrade PR lands). We can upgrade the zig template to use zig 0.13.0 by copying the builtins from the branch, and then convert that into a zig package.
When we generate glue for zig using ZigGlue.roc
it can use the zig package.
I figured it'd be easier to work in the Roc repo, as I just finished setting up end-to-end tests for Zig platforms there
Or do I misunderstand
Last updated: Jul 06 2025 at 12:14 UTC