Is there a scenario for hosting the roc compiler in my own CLI?
I have my own toolchain and I am wondering if I can do the roc compilation for my own custom platform using my own CLI, so that users would not need to directly invoke roc?
Also I'm new here so I might be way off base with what I'm thinking. I'm imagining kind of like what javy
from the bytecodealliance/shopify enables you to do by consuming their crates.
My understanding is that the Roc code that's being called from a platform (i.e., from the host is essentially an already-compiled shared library).
I hope this does clarify matters a bit. It doesn't seem to me what you're actually after is hosting the Roc compiler.
I have to admit I'm not familiar with the javy
project.
Update: Having thought about your use-case in more detail and having looked up javy
briefly, I think I have a bit better understandasing of your use-case.
I'll let the more knowledgeable members share their opinion on this one, as I'm afraid I couldn't be of help.
@Damian Reeves do you also want to compile to wasm like javy?
Yes I do
:+1: what language does your "own custom platform" use?
So my "custom platform" can be theoretically written in any language though it is usually Elm (and perhaps Scala or Bosque), but the main thing is the language frontend produces a Mophir IR file that is a JSON file (or multiple IR JSON files if you have dependencies).
I have multiple use-cases I have in mind but the main is I want to be able to run my compiler, produce my IR (as JSON), and produce webassembly... I believe I can produce Roc from my IR since my IR maps very well to Elm.
I also want to be able to natively test from my CLI as well.
So all these usecases kind of require me to use the underlying functionality of Roc to build my own toolchain.
In the end I also want to take advantage of Roc's platforms as users often want to bind their model to execution on some platform that expects entry points with specific signatures (this is why I think Roc is such a good fit).
The main thing is I don't want to need to tell my users to install my CLI (morphir CLI), install roc, install rust or clang and all this other stuff to produce their thing that runs on my platform.
They want to write their app, which you can think of as something that will run a calculation that will work on their specific runtime. The output of compiling their app should be agnostic of the host it is being ran on (which is why I want to target webassembly since it runs on all hosts we target
The main thing is I don't want to need to tell my users to install my CLI (morphir CLI), install roc, install rust or clang and all this other stuff to produce their thing that runs on my platform.
Right, that should be achievable, what targets do you plan on supporting? e.g. macos-aarch64, macos-x86-64, linux-x86-64, linux-aarch64, windows-x86-64 etc.?
By targets I don't mean wasm of course, but the type of computer your users will run your CLI on
That list seems sufficient: macos-aarch64, macos-x86-64, linux-x86-64, linux-aarch64, windows-x86-64. Potentially gravatron as well
But I'm no expert on the gravatron struff (I might even be spelling it wrong)
linux-aarch64 and windows-x86-64 currently still have some issues but macos-aarch64, macos-x86-64 and linux-x86-64 should work. Given that set, I would recommend creating one .sh script that can install everything in one go. I'm not sure which dependencies are required to compile to wasm, perhaps others can weigh in?
Coming back to this and wondering if just distributing roc alongside my CLI would be sufficient? What I am not sure is can I do that? Can I distribute roc with my tool?
Also guess it depends on the state of things like rocup?
Can I distribute roc with my tool?
Yes, just make sure to include the Roc license somewhere too.
Also guess it depends on the state of things like rocup?
We plan to include rocup functionality in the roc command. Note that your Roc code (inside your CLI tool?) may not work if you "blindly" update to the latest Roc version.
Last updated: Jul 06 2025 at 12:14 UTC