Module Make.Load
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