TL;DR Is there a (preferably straightforward way) of installing the OCaml runtime, separately from the compilers and other tools in the base OCaml distribution?
Hi all,
I’m coming back to OCaml after almost a decade away and I’m thinking about porting some of my utilities from various “lowest common denominator languages” (i.e., mostly Bash and Python) to OCaml. I’m wondering about the best way to distribute these to colleagues who are not OCaml users. I’ve seen discussions about the obvious portability of the bytecode combined with how ocamlrun is easily compilable with a standard C compiler.
However, in practice, I haven’t found anything on distributing or installing just the interpreter and runtime, separately from the rest of the tooling in the OCaml repository. I also haven’t found any Opam package (so far) that would appear to only include the runtime and standard library for running OCaml programs. How are people distributing their programs, at least to the various POSIX-conforming platforms, other than targeting them directly with native code? If there isn’t currently anything in place, would there be interest in extracting the bytecode runtime into a separate Opam (potentially, Homebrew/apt/Nix/whatever) package?
If you want to distribute bytecode executables rather than native executables (why?), the ocamlc'-custom' option may do what you want. It will link the runtime into the executable to allow separate distribution. The manual says this:
-custom:
Link in “custom runtime” mode. In the default linking mode, the linker produces bytecode that is intended to be executed with the shared runtime system, ocamlrun. In the custom runtime mode, the linker produces an output file that contains both the runtime system and the bytecode for the program. The resulting file is larger, but it can be executed directly, even if the ocamlrun command is not installed. Moreover, the “custom runtime” mode enables static linking of OCaml code with user-defined C functions, as described in chapter 22.
When compiling a bytecode executable, I believe dune uses custom mode by default. Obviously this won’t help if you want to distribute your programs to colleagues in source code form as a script. Your colleagues would I think then need a compiler.
Obviously, recommending ocamopt, -custom etc. is not responsive.
Some kind of “ocamlrun only” package might be useful, but you might run into versioning issues - I’m not sure how portable bytecode is across complier versions. Plus the only diff is that bytecode stuff does not need a c compiler - but you’d need a c compiler anyway to build ocamlrun.My guess is that the easiest thing to do ATM would be to recommend installation of the SDK without opam. That would give your colleagues the ocamlrun they need to run your stuff. Other stuff too but they can ignore that. The alternative would be to distribute ocamlrun binaries. That seems reasonable to me.
That is of course in effect what the (not responsive) -custom option does, except that linking with -custom builds the runtime system into the bytecode executable. The advantage of that is that it avoids versioning issues.
ocamlrun can run any bytecode executable. A -custom executable can only run itself (I think).
This really gets back to the question of why one would compile to bytecode. One reason would be to make OCaml Java-like - distribute bytecode to people who have the OCaml VM (ocamlrun) installed.
I’m under the impression that the more common reason is to speed development. Compiling to bytecode is noticeably faster than compiling to native code.
If I’m not mistaken, at least part of the reason dune favors -custom is because it statically links C/C++ libraries. If you link bytecode that depends on such a library and you do not use -custom then you have to deal with linking shared libs, which is more error-prone.
And there is also -output-complete-exe. But if you’re going to go to the trouble of that or -custom you might as well use aocamlopt since either way you won’t be distributing a bytecode-only executable.
Currently, if portability is your primary concern, I have developed an OCaml to Cosmopolitan/APE port that provides a new OCaml toolchain capable of producing actually portable executables. An example in the README.md file shows how to use such this toolchain. The support is only for OCaml 4.14, but I have OCaml 5 on my to-do list.
Actually, it can run other things, although I think that’s unintentional (and bad) and one of the many bits of spin-off work from Relocatable OCaml is stopping that from being the case.