Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parallelise building dynlink_compilerlibs #3250

Merged
merged 1 commit into from
Nov 12, 2024

Conversation

lukemaurer
Copy link
Contributor

This performs two weird tricks that together knock ~30 seconds off the build time in dev mode and ~40 seconds outside dev mode:

  • To build dynlink_compilerlibs, copy both parser.ml and parser.mli from the main compiler source rather than just parser.ml. Copying just parser.ml means that the native build depends on the .cmi produced by the bytecode build.

  • Explicitly add the .cma and .cmxa files for dynlink and flambda2_from_lambda to the install alias. It's not clear why this helps, but it appears that Dune is being excessively lazy in discovering installable targets, waiting until ocamlcommon is built before it even considers any targets in these libraries, including those that don't depend on ocamlcommon (and take quite a while to build). Redundantly adding targets to install seems to be the nudge Dune needs.

This performs two weird tricks that together knock ~30 seconds off the build
time in dev mode and ~40 seconds outside dev mode:

- To build `dynlink_compilerlibs`, copy both `parser.ml` and `parser.mli` from
  the main compiler source rather than just `parser.ml`. Copying just
  `parser.ml` means that the native build depends on the .cmi produced by the
  bytecode build.

- Explicitly add the .cma and .cmxa files for `dynlink` and
  `flambda2_from_lambda` to the `install` alias. It's not clear why this helps,
  but it appears that Dune is being excessively lazy in discovering installable
  targets, waiting until `ocamlcommon` is built before it even considers any
  targets in these libraries, including those that don't depend on `ocamlcommon`
  (and take quite a while to build). Redundantly adding targets to `install`
  seems to be the nudge Dune needs.
@stedolan
Copy link
Contributor

I am really looking forward to the cleansing fire of ocaml/ocaml#11996 that will arrive with 5.3, but in the meantime this looks great. (Might also be worth asking a Dune person to have a look at why adding flambda2_from_lambda helps? Seems like that might be a Dune bug).

@stedolan stedolan merged commit 9acd771 into ocaml-flambda:main Nov 12, 2024
19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants