In some cases, we are only interested by the toplevel side effects of dynlinked modules.
val load_ocaml_src_files : 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 ‑> 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 ‑> 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