@Luke Boswell If you are willing to touch roc preprocess again, it could me useful to change the arguments again.
I know, that I advocated to use files instead of folders, but maybe this was not useful.
When you call roc preprocess, you already created the dynhost. This file has to be inside your platform. So the path is always PATH/TO/PLATFORM/dynhost. I don't think it is necessary to give the dynhost as an argument. The path can be calculated by the other arguments.
I believe, that at the moment, the main roc file inside the platform has to have the name main.roc and it has to be inside the platform directory. So it can not be used from some cache location like the zig-build-cache. Therefore it should only be necessary to give the path to the platform. The main roc file can then be found by appending main.roc.
The libapp.so file on the other hand could be anywhere inside the host code, or even in a build-cache. So it is necessary to provide the path.
In conclusion I would propose roc preprocess PATH/TO/PLATFORM/ PATH/TO/libapp.so.
As an alternative: roc preprocess PATH/TO/PLATFORM/main.roc PATH/TO/libapp.so.
What do you think?
When you call
roc preprocess, you already created thedynhost. This file has to be inside your platform. So the path is alwaysPATH/TO/PLATFORM/dynhost.
This was implemented based on @Brendan Hansknecht's feedback in this PR.
At the time I recall we still needed to depend on the dylib and that is why we have three arguments.
I think we can remove the dependency on an actual dylib and the stub symbols. So I think we should remove both of those. The only piece of information we actually need is what shared library the host thinks it linked to such that we can remove that dependency during preprocessing.
I also think this is possible, but I haven't given it a serious try yet. My thoughts are to land the host rebuilding PR first as that is a massive cleanup of the build pipeline.
Ok, so this is already in planing. Perfect :+1:
Oskar Hahn has marked this topic as resolved.
Last updated: Jun 16 2026 at 16:19 UTC