Add Hermes CI coverage#1736
Conversation
Point JsRuntimeHost at the Hermes integration branch and add Win32 x64 D3D11 plus Android Hermes CI coverage. Import host Hermes compilers for Android cross-compilation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR adds CI coverage for the Hermes JavaScript engine by wiring Hermes as a selectable engine in existing CI workflows and updating the Android Playground build to support importing Hermes host compilers.
Changes:
- Point
JsRuntimeHostFetchContent dependency at a Hermes integration branch. - Add Win32 x64 D3D11 + Hermes CI job.
- Add Android (Ubuntu) + Hermes CI job and pass host compiler import into the Android CMake build via Gradle.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
CMakeLists.txt |
Switches JsRuntimeHost source to a Hermes integration branch. |
Apps/Playground/Android/BabylonNative/build.gradle |
Refactors CMake argument construction and adds optional host compiler import argument passing. |
.github/workflows/ci.yml |
Adds Win32 Hermes and Android Ubuntu Hermes jobs to the main CI matrix. |
.github/workflows/build-win32.yml |
Extends engine selection logic to include Hermes (NAPI_JAVASCRIPT_ENGINE=Hermes). |
.github/workflows/build-android.yml |
Builds Hermes host compilers (for Ubuntu Hermes CI) and passes their import script into Gradle. |
Install the Linux host dependency needed by BabylonNative's Hermes host-tool configure and disable Boost.Context for Hermes CI builds to avoid the Windows MASM object link issue. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Avoid configuring BabylonNative's full dependency graph for the Android Hermes host compiler build. Build the host Hermes tools directly from the JsRuntimeHost Hermes integration branch instead. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Expose globalThis and a canvas alias from the native Playground host so evaluated playground snippets can resolve browser-style globals under Hermes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Keep Win32 Hermes building and running non-visual tests, but skip Playground visual validation until Hermes has the browser-compatible canvas path required by some validation snippets. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add Ubuntu clang Hermes coverage, skip visual validation for Hermes Linux builds, and address Copilot review feedback on Gradle quoting plus macOS Ninja availability for Android Hermes host tools. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Ubuntu clang Hermes covers configure, build, and UnitTests. Skip ModuleLoadTest for Hermes because its expected boot-module snapshot is engine-specific and currently fails under Hermes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Run Playground validation for Win32 Hermes targets so failures are visible in CI while the integration is being brought up. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Expose the validation engine and canvas on globalThis so evaluated playground snippets that reference browser-style globals work under Hermes eval scoping. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Run validation, module-load, and rendered-picture upload for Linux Hermes builds as well. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…nto hermes-integration # Conflicts: # CMakeLists.txt
Add the exact ICU and liblzma shared libraries loaded by Hermes on ubuntu-latest to the Linux ModuleLoadTest expected boot module set. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
# Conflicts: # CMakeLists.txt
CedricGuillemet
force-pushed
the
hermes-integration
branch
from
9e7b01a to
4e6618d
Compare
ryantrem
left a comment
ryantrem
left a comment
There was a problem hiding this comment.
Can you update the docs to explain what a BN consumer needs to do to use Hermes? It seems like it is more than just switch the compile flag (like JSC vs. v8 for example).
| if: inputs.js-engine == 'Hermes' | ||
| run: | | ||
| git clone --depth 1 --branch hermes-integration https://github.com/CedricGuillemet/JsRuntimeHost.git Build/JsRuntimeHostHost | ||
| cmake -B Build/HermesHost -G Ninja -S Build/JsRuntimeHostHost \ |
There was a problem hiding this comment.
Will this need to be done by BN consumers as well then?
There was a problem hiding this comment.
I've reworked that part so the hermes toolchain is handled by JSRuntimeHost transparently.
| FetchContent_Declare(JsRuntimeHost | ||
| GIT_REPOSITORY https://github.com/BabylonJS/JsRuntimeHost.git | ||
| GIT_TAG c88625b6d61b55c4589f02408d03826e83199870) | ||
| GIT_REPOSITORY https://github.com/CedricGuillemet/JsRuntimeHost.git |
There was a problem hiding this comment.
Putting a note here just to make sure it doesn't get forgotten - update to the new commit after the JsRuntimeHost PR is merged.
Resolved conflicts: - CMakeLists.txt: keep JsRuntimeHost pinned to CedricGuillemet fork @ hermes-integration; drop the libwebp FetchContent_Declare to follow upstream (BabylonJS#1740 removed libwebp; WebP now via bimg's bundled decoder). - Apps/Playground/Shared/AppContext.cpp: deleted upstream by the Embedding API refactor (BabylonJS#1701). Migrated the Hermes globalThis/canvas global-object polyfills into the Embedding layer's JS-init dispatch (Embedding/Source/Runtime.cpp). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| // Hermes for Android needs HOST hermesc/shermes (they emit bytecode at build | ||
| // time and can't run as NDK-cross-compiled binaries). JsRuntimeHost's CMake |
There was a problem hiding this comment.
Is the Hermes compiler (hermesc) only required to load Hermes bytecode? I thought this first round of changes was for loading JS bundles only? Does Hermes support loading either JS or ByteCode, and is this a platform specific question?
There was a problem hiding this comment.
hermes has some polyfills (promise, async function, iterator helpers) that are compiled into byte code. And that bytecode is embedded in hermes static library. Hermes can run bytecode or .js (but in that case, it compiles to bytecode internally and run that produced bytecode, transparently). not specific to a platform.
There was a problem hiding this comment.
Oh I see, interesting. And you can also compile your own JS to bytecode ahead of time so that at runtime you only load the bytecode, right?
There was a problem hiding this comment.
yes, it's the exact same as QuickJS. I tried QuickJSC and the bytecode was bigger than the source .js. idk the footprint for Hermes.
Summary
Notes