On 21/11/2007, Alain Frisch <alain@frisch.fr> wrote:
>
> viktor tron wrote:
> > This is now my third project where an ocaml implementation needs a c
> > binding and I keep on struggling
> > with the right build environment.
>
> What you want is a main program in C, with some services provided by
> OCaml code, right?


Alain, thank you very much for taking your time and clarify things for me.
Well, the MAIN program can be anything that can handle a correct C-lib.
Actually, I had projects in C++, C, Ruby that called my lib.
In fact, my next assignment is a .NET integration so your C# example will be
a lifesaver for me I guess.

Anyway, in the current development branch on OCaml, it is possible to
> build a dynamic library that contains the OCaml runtime + arbitrary
> OCaml and C code, in a platform-independent way. This is similar to
> linking a main program, but the result is linked as a DLL.


This is super! how is this on MacOS, I recall one of your comment
earlier (on this list?)
that it doesn't work or something.


> Cf the test2 and testopt2 targets in:
>
> http://camlcvs.inria.fr/cgi-bin/cvsweb/~checkout~/ocaml/test/outputobj/Makefile



(This is an example of a main program in C#, but the same technique also
>   works for a main program in C. In addition, the example uses the
> Dynlink module, but this is orthogonal to your questions.)


Very cool, I will have a thourough look.

> * what do I do if I don't want to compile the ocaml runtime into my lib,
> > since they might use several
> > of my modules so just link at the end with the runtime lib
>
> Well, if you don't want to compile the ocaml runtime into your lib, just
>   don't do it. Simply create an archive with the .o produced by
> -output-obj and your C code. Or don't create an archive at all and link
> everything directly into your final executable.
>
> See Section 18.7.5 of the OCaml manual.


well, I tried.
ar -rs foo_caml.o foo_stub.o

but then I get linking errors:

gcc -o foo_test.native foo_test.c -L. -lchainfreq_native -L/sw/lib/ocaml
-lasmrun
/usr/bin/ld: Undefined symbols:
_caml_apply2
...
lots of other symbols

I guess I am missing something pretty trivial here, so apologies to the
savvy.


> * how do I create dynamic libs, dlls for windows?
>
> What do you want to put in your dynamic libs? If you want to create a
> "stand-alone" dll with the OCaml runtime + arbitrary OCaml and C code,
> the new behavior of "-output-obj -o XXX.{so,dll}" is/will be what you
> want.


and not standalone ones?

> * omake is serious overkill (after hours of reading through the manual,
> > I still don't know how the gtk example is relevant, plus omake creates
> > an extra problem for portability, please correct me if I am wrong)


Quite the contrary, I would say. Portability seems like a very
> compelling reason to adopt omake. It works very nicely under Unix and
> Windows.


yes, in general omake is super appealing, but (a) every dependency my
software relies on
discourages/angers users. It is already a pain for people to have the ocaml
compiler and a shell
already. I know this is another
world... (b) I still don't know how it would help automate my problem
yet, as I said the gtk example is a serious overkill.

On a sidenote to this issue, the rocaml package uses a camlp4 extention to
create callback registration and automates the creation of a stub file. (And
as far as I understood, omake does something similar).
Since most of my callbacks use a pretty simple API (meaning I don't have to
deal with conversion of esoteric ocaml types), the whole process could
easily be automated and integrated in my build template.

Viktor