this is a partially-formed idea, so I'd like to talk about it at a high level and see what others think!
I was thinking about how if I'm embedding a Roc program inside another code base (e.g. what we'll be doing in Vendr, introducing Roc to the existing TypeScript backend using a custom TS platform that lets the TS code base call Roc functions), and what the workflow would be like with the current roc glue and roc build designs.
for example, right now I think it's:
roc build on my application, and since my platform is coming from a path on my local filesystem, it will get rebuilt every timeroc glue every time that happens, or else I'll get UBwhat if instead we made it so that the glue spec was specified in the platform module, and every time the platform gets rebuilt (either from the application rebuilding it or from running roc build on the platform module), glue generation gets re-run automatically?
at first I thought "oh that would be slower" but then I thought about it some more and it seems like it might be the same speed or faster in practice :sweat_smile:
because glue generation already requires monomorphizing the entire platform; the only thing it's doing differently from roc build is skipping the code gen step
but once monomorphization is done, glue gen and code gen can be done concurrently
which would probably mean that in practice, glue wouldn't actually be any slower unless every core is tied up I guess - which could happen on a CI machine, for example, but on a CI machine you'd want to run glue+build anyway, so in that scenario you get a savings from not having to do parse, canonicalize, typecheck, monomorphize twice (once for roc build and then again for ` roc glue) - or, in a world where we have incremental builds, having to wait for the cache check an extra time
so the only scenario that would get slower is the specific case where you'd want to build the platform but not re-run glue
but caching during builds would completely address that; we'd already want to detect when there were no changes that could affect glue since the previous build, and therefore not bother to run it
and that check could run in parallel to code gen, so again probably not actually slowing down the end-to-end runtime in practice
so one specific idea would be to specify the glue using the usual packages syntax packages { pf: ..., glue: "https://..." } and then add something like generates glue to the platform header
this way, the platform knows what glue is supposed to be used to generate it, and when you run roc build you always get up-to-date glue as well as an up-to-date binary
so the "I was getting segfaults for two hours because forgot I needed to manually run glue" bad experience can't happen
thoughts?
This sounds really neat. Would there ever be a need to have glue generated for multiple architectures? How might that work?
Glue already supports multiple architectures
We pass the type layout for each architecture into the glue gen scripts and they can generate whatever is needed in the platform's programming language. We use cfg attributes in rust.
So this seems like a really strange merging to me. Fundamentally, roc glue will mostly be used by platform authors, not by regular roc developers. Obviously there will be custom platforms and overlap, but as roc matures and more base platforms are built, that should become a less common use case.
Not against it. Just don't think it will be that common. Also, we have a goal trying to ensure build is fast and this goes directly against it.
So i guess i see the specific use case, but if you have another build system that is calling roc build, why not just make that build system also call roc glue.
Especially since whenever you need to run roc glue you likely will also need to change something on the systems side of the platform. You probably can't just safely call roc glue
Fundamentally whenever you need to run roc glue, you are changing the contract between roc and the host language.
Last updated: Jun 16 2026 at 16:19 UTC