Js_of_ocaml: share standalone runtimes#13621
Conversation
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>
|
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. |
| tests js_of_ocaml conigs | ||
|
|
||
| $ dune build bin/bin1.bc.js bin/bin2.bc.js bin/bin3.bc.js | ||
| $ dune build bin/bin1.bc.js bin/bin2.bc.js bin/bin3.bc.js --display short |
There was a problem hiding this comment.
Please don't use the output of --display short in tests. It creates a bunch of noise for others as the output of such commands are often re-ordered. Prefer to use trace events and only output what your test is trying to observe. Search for dune trace cat in the test suite to see examples on how to do this. If it's still unclear, just let me know and I help further.
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.
3 participants
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?