Re: [Caml-list] whither portability?

[whitequark <whitequark@whitequark.org>]

I will offer a few comments as the author of opam-android[1].

On 2015-09-26 15:48, Raoul Duke wrote:
> Exciting to hear! Thank you and your contributors for this work. I
> know there are ways people can be parochial, but I have never been
> able to fathom how the core OCaml team can ignore mobile so actively,
> it seems. It is to sigh, oy veh.

No one is being parochial or "actively" ignoring mobile. The OCaml core
team consists of unpaid volunteers. I suggest that next time, in place
of a snide remark, you contribute some code and/or money.

That being said...

> 
> Throwing out random ideas as a potential some-day user of such a thing:
> 
> * Getting anything working as simply as possible would be a nice first
> step, even if it isn't the most performant. I.e. bytecode. It seems
> Apple has loosened up on that a bit over the years? And I wonder if
> LLVM bytecode would be no problem with them now.

Both ocamlc and ocamlopt work for iOS and Android; there is not really
a good reason to use the bytecode compiler for deployment to mobile.

There is no such thing as "LLVM bytecode" and LLVM bitcode (sic)
is merely an intermediate format for native executable code. Shipping
LLVM bitcode offers no conceptual improvement over shipping
machine code and in any case, there is neither an LLVM backend
for ocamlopt nor much need for such a backend.

> 
> * FFI will be essential. It is one thing to have 2+2 working on
> mobile, it is another to be able to get any real app work done. (In
> the past I have had some negative experiences with OCaml and FFI for
> OpenGL so I am always a little worried about trying to reignite my
> relationship with OCaml.)

Definitely. ocaml-ctypes[2] in cstubs mode allows bidirectional
integration of OCaml code with C code, i.e. OCaml can call into C
and C can call into OCaml. Daniel Bünzli's tgls OpenGL bindings
can be made to compile in cstubs mode, but this is not quite
upstream yet[2].

> 
> * Ideally it has to integrate well with the platform toolchains,
> including the preferred IDEs. E.g. if there's no good installer, if I
> have to do a lot of work to build things, etc., then I'm way less
> likely to even try to use it. I know that is work most people do not
> like to do. I say that empirically.

With opam-android, the workflow is exactly identical to building any
regular OCaml project, with the difference that the final binary 
produced
is a .o or .so file that you can use as any other C library in
your Android project; the Android cross-toolchain is just another switch
in opam.

I don't know how it works for iOS but it is almost certainly possible
to achieve the same level of convenience.

[1]: https://github.com/whitequark/opam-android
[2]: https://github.com/dbuenzli/tgls/pull/14

-- 
whitequark