Load contains functions similar to the ones above, and can be used if you want to
separate extraction of the compiler from building/loading files. It can be useful if
you want to extract the compiler upfront (to improve latency a bit) or if you want
to share the cost of extracting the compiler for the current executable over
multiple compilations. Probably not needed by the casual user.
val load_ocaml_src_files : Dynloader.dynloader ‑> string list ‑> t Async.Deferred.Or_error.tLoad a bunch of ocaml files source files (.ml + .mli). The last module's signature
should be compatible with the signature X.repr. If the type does not match, there
will be an error during OCaml compilation. The files are copied into the compilation
directory, and compiled versus a generated mli file including the relevant module
signature. This generated file is then dynlinked with the current executable.
The compilation happens using Dynlink.loadfile_private, meaning that
the toplevel definition defined in these files are hidden
(cannot be referenced) from other modules dynamically loaded afterwards
val load_ocaml_src_files_without_running_them : Dynloader.dynloader ‑> string list ‑> (unit ‑> t) Async.Deferred.Or_error.tLoads the given source files, same as load_ocaml_src_files, but instead of running
their toplevel, you are given a closure that will run the toplevel. You can use this
to run the toplevel multiple times, or lazily, or outside the async thread, or get
precise control over the raised exceptions.
val check_ocaml_src_files : Dynloader.dynloader ‑> string list ‑> unit Async.Deferred.Or_error.tSimilar to load_ocaml_src_files, but does not execute the plugin toplevel, just
checks that compilation and dynamic linking work.
module Expert : sig ... end