Module Dynloader.Side_effect
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