Stream: ideas

Topic: glue generation as part of `roc build`


view this post on Zulip Richard Feldman (Apr 15 2023 at 03:12):

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:

what 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?

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:12):

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:

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:13):

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

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:14):

but once monomorphization is done, glue gen and code gen can be done concurrently

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:16):

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

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:16):

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

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:17):

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

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:18):

and that check could run in parallel to code gen, so again probably not actually slowing down the end-to-end runtime in practice

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:19):

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

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:20):

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

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:20):

so the "I was getting segfaults for two hours because forgot I needed to manually run glue" bad experience can't happen

view this post on Zulip Richard Feldman (Apr 15 2023 at 03:20):

thoughts?

view this post on Zulip Luke Boswell (Apr 15 2023 at 04:38):

This sounds really neat. Would there ever be a need to have glue generated for multiple architectures? How might that work?

view this post on Zulip Brendan Hansknecht (Apr 15 2023 at 05:27):

Glue already supports multiple architectures

view this post on Zulip Brendan Hansknecht (Apr 15 2023 at 05:28):

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.

view this post on Zulip Brendan Hansknecht (Apr 15 2023 at 05:30):

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.

view this post on Zulip Brendan Hansknecht (Apr 15 2023 at 05:32):

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.

view this post on Zulip Brendan Hansknecht (Apr 15 2023 at 05:32):

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.

view this post on Zulip Brendan Hansknecht (Apr 15 2023 at 05:35):

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

view this post on Zulip Brendan Hansknecht (Apr 15 2023 at 05:36):

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