Js_of_ocaml: share standalone runtimes#13621
Merged
rgrinberg merged 3 commits intoocaml:mainfrom Mar 17, 2026
Merged
Conversation
Collaborator
|
I wanted to explore another direction where we would emit a minimal runtime based on requirement from individual units. Either having That said, I like the current PR. |
hhugo
approved these changes
Feb 13, 2026
rgrinberg
requested changes
Feb 21, 2026
vouillon
force-pushed
the
jsoo-shared-runtime
branch
3 times, most recently
from
42ab11e to
8025dad
Compare
vouillon
force-pushed
the
jsoo-shared-runtime
branch
from
8025dad to
8f9ac22
Compare
Collaborator
|
@rgrinberg, I think this is ready |
Collaborator
|
@vouillon, this needs to be rebased |
When dune builds `(executables (names a b c))` in separate compilation mode, it previously ran `js_of_ocaml build-runtime` once per executable. Since all executables in the same stanza share the same compilation context, the runtimes are identical. This change builds one shared runtime per stanza per mode, eliminating redundant work. Signed-off-by: Jérôme Vouillon <jerome.vouillon@gmail.com>
Phase 1 shared one runtime per (executables ...) stanza. This commit eliminates remaining duplication by sharing runtimes across all stanzas in the workspace that link the same set of runtime-contributing libraries. Following the PPX driver sharing pattern (Key module + on-demand rule generation), a Runtime_key module encodes (mode, lib_names, project_root) into a digest. Stanzas with no user javascript_files/wasm_files get a Shared digest; others keep per-stanza behavior. Shared runtimes are built on-demand at .js/<config>/.runtime/<digest>/ when first requested, with the config resolved dynamically at build time to ensure correctness across directories with different env configs. Signed-off-by: Jérôme Vouillon <jerome.vouillon@gmail.com>
Use dune trace cat | jq to extract deterministic sorted target lists instead of --display short which produces unstable build step ordering. For install tests, use find | sort instead of install log output. Signed-off-by: Jérôme Vouillon <jerome.vouillon@gmail.com>
vouillon
force-pushed
the
jsoo-shared-runtime
branch
from
8f9ac22 to
88620d2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
At the moment, in separate compilation mode, we are building one custom runtime per executable, even though the same runtime could be used by the different executable.
The first commit implement the sharing at the level of a stanza, while the second commit extends it to workspace-wide sharing.
I'm not completely sure the added complexity is worth it. A clean run of the Js_of_ocaml test suite go from 3 minutes down to 2m40 with this change, but it's kind of extreme.
@hhugo What do you think?