flan/spike/embed/harness3.c
Joseph Ferano d272a5b1e5 Six probes for whether the OCaml compiler can live in the game's process
Item 12 asks five questions and says to answer them with a spike rather than a
rewrite. spike/embed/ is that spike: one script, six binaries, each one built to
fail loudly at the thing it is asking about. It is deliberately not a dune
target -- the root dune only excludes old-ocaml/, so a dune file here would land
in @default and make the spike part of the build. It drives ocamlfind and clang
by hand against the flan.cmxa dune already produces.

The probes, in the order they would kill the idea: the smallest possible link, a
C main() reaching one OCaml function; the whole compiler linked in and doing
real work; the same again with lib/dynload_stubs.c from the unmerged dlopen
branch, because that is the only C the compiler itself is built from; the game
keeping the main thread while caml_startup happens on a pthread beside it; the
SIGSEGV disposition read on both sides of caml_startup; and an 8 MiB arena
checked byte for byte across a compaction.

No result is written down yet. This is the apparatus.
2026-09-12 20:27:45 +07:00

15 lines
462 B
C

/* Step 3: does -output-complete-obj carry the project's C stubs through? */
#include <caml/callback.h>
#include <caml/mlvalues.h>
#include <stdio.h>
int main(int argc, char **argv) {
const value *f;
(void)argc;
caml_startup(argv);
f = caml_named_value("spike_stubs");
if (!f) { fprintf(stderr, "spike: stubs not registered\n"); return 1; }
printf("stubs reached from embedded runtime: %s\n", String_val(caml_callback(*f, Val_unit)));
return 0;
}