I have investigated with cross compilation for android and ios. I got things working on android (and probably ios if I can get a copy of XCode) using js_of_ocaml and cordova following instruction here:
GitHub - dannywillems/ocaml-cordova-example: Example of the binding to the cordova object
But this is rather unsatisfactory (too many layers) and I would prefer native compilation, especially that with 5.0 coming soon, the fact that js_of_ocaml allows threading is no more an issue).
unfortunatelly, opam-cross-android and opam-cross-ios seem outdated (see OCaml cross-toolchains and cross-packages · GitHub). Is there somewhere tools and instructions to build application with latest OCaml on multiplateform ?
Take a look at @EduardoRFS 's reason-mobile project.
I’m fairly sure you will be waiting a while for multicore support for Android and iOS, if that is what you meant by “multiplatform”. Multicore on other supported platforms will be ahead in the queue.
I’d be curious to know if you really want to use multiple cores for OCaml in a mobile app. IMHO: Since there are usually only a couple high-performance cores on an everyday phone, and since overuse / incorrect use of mutexes is very noticeable (bad) to a mobile user, I want concurrency but not parallelism in mobile apps. Concurrency in OCaml 4.x is good, and concurrency in OCaml 5.x with effects handlers should be great. I want OCaml 5.x multicore (parallelism) really only for running OCaml faster+cheaper on backend Linux servers
I would probably echo the excellent suggestions of @jbeckford in that
reason-mobile is probably the best way to go about this right now.
If, however, you fancy something very experimental I have an outdated repository that compiled an older Multicore OCaml for the x86 iPhone simulator: GitHub - patricoferris/eios: Effects on iOS. This uses the opam-monorepo and dune-workspaces approach to cross-compilation, like Mirage 4 will. The point of this approach was to try out effect handlers for concurrency using the portable eio library with an iOS compatible backend (one that uses Dispatch (GCD) for IO and network.framework).
As I mentioned, it is outdated. It uses an old Multicore, an old Eio and an old GCD backend for Eio. If I find some time soon I will try to bring everything up to date :))
Thanks, I wanted to try … But what is esy? It is very hard to find on google/apt-cache search/opam search
For multicore, I am in a context where one or more thread is doing a physical simulation and one thread is doing
GL displaying for a game. This needs in general none or very little mutexes, using continuity of the data evolution in time and fixed point arithmetics (or if double have atomic read and write). I tested this with processes and shared memory in OCaml using mmap and it works relatively well and the GC is not even a problem.
OK I found it … it is a node modules …
Esy is actually another package manager. See https://esy.sh/