The net result of this PR is the roc binary in the release package is able to run the nodejs-interop/wasm example using the instructions in the README.
The release package now looks like:
$ earthly +build-nightly-release --RELEASE_FOLDER_NAME=out
$ tar tf out.tar.gz
(truncated for brevity where globs are shown)
out/
out/examples/**
out/crates/
out/crates/compiler/builtins/bitcode/*
out/crates/roc_std/**
out/roc
out/roc_language_server
out/lib/
out/lib/wasi-libc.a
out/LICENSE
out/LEGAL_DETAILS
The original issue was the roc CLI was using the WASI_LIBC_PATH to lookup the path to wasi-libc.a. When building locally this would work fine. This would end up pointing to $PROJECT_ROOT/target/$PROFILE/build/wasi_libc_sys-$BUILD_ID/wasi-libc.a. In the release package this would result in the roc binary looking for the library in the static location of /earthlybuild/... which inevitably would not exist on the end user's machine. The new logic for the wasi-libc.a lookup matches the logic for looking up zig glue where it checks in a lib folder next to the binary. This logic works for the current release format assuming the user keeps the contents of the release package together and either executes roc from the package or symlinks the roc binary into their path.
Potential followup:
There are a few points of cleanup that I think are probably good followup work, but since I am a new contributor I did not want to change too much in this initial PR.
Given that WASI_LIBC_PATH rarely points at what you want I suggest removing the public constant and the machinery that sets it so it is not misused in the future.
The WASI_COMPILER_RT_PATH is generated in the same way the WASI_LIBC_PATH constant is. Given the issues I found with WASI_LIBC_PATH I would suggest investigating WASI_COMPILER_RT_PATH does not have the same issues. I did not have enough context to trigger the errors that would be caused by misuse of this constant.
The git clean call in the package_release.sh seems redundant and should be removed since the environment being cleaned is disposed at the end of the build anyways.
This PR addresses the following issues:
6029
5573
The net result of this PR is the roc binary in the release package is able to run the
nodejs-interop/wasmexample using the instructions in the README.The release package now looks like:
The original issue was the roc CLI was using the WASI_LIBC_PATH to lookup the path to
wasi-libc.a. When building locally this would work fine. This would end up pointing to$PROJECT_ROOT/target/$PROFILE/build/wasi_libc_sys-$BUILD_ID/wasi-libc.a. In the release package this would result in the roc binary looking for the library in the static location of/earthlybuild/...which inevitably would not exist on the end user's machine. The new logic for the wasi-libc.a lookup matches the logic for looking up zig glue where it checks in a lib folder next to the binary. This logic works for the current release format assuming the user keeps the contents of the release package together and either executes roc from the package or symlinks the roc binary into their path.Potential followup:
There are a few points of cleanup that I think are probably good followup work, but since I am a new contributor I did not want to change too much in this initial PR.
WASI_LIBC_PATHrarely points at what you want I suggest removing the public constant and the machinery that sets it so it is not misused in the future.WASI_COMPILER_RT_PATHis generated in the same way theWASI_LIBC_PATHconstant is. Given the issues I found withWASI_LIBC_PATHI would suggest investigatingWASI_COMPILER_RT_PATHdoes not have the same issues. I did not have enough context to trigger the errors that would be caused by misuse of this constant.git cleancall in thepackage_release.shseems redundant and should be removed since the environment being cleaned is disposed at the end of the build anyways.