* Re: [Caml-list] embedding Ocaml in an existing application
2001-12-06 21:28 [Caml-list] embedding Ocaml in an existing application Basile STARYNKEVITCH
@ 2001-12-08 16:09 ` Xavier Leroy
0 siblings, 0 replies; 2+ messages in thread
From: Xavier Leroy @ 2001-12-08 16:09 UTC (permalink / raw)
To: Basile STARYNKEVITCH; +Cc: caml-list
> Some remarks (and wishes) about embedding Ocaml (bytecoded) in an
> existing application.
> [...]
> First remark: the ocaml linking mechanism use the undocumented -p
> flag to dump all the Ocaml symbol table.
Only for the -use-runtime linking mode, which I think is not required
at all for what you're doing (embedding an OCaml program and the
OCaml runtime inside a larger program). The "-use-runtime" and
"-make-runtime" linking modes are just a variation on "-custom"
linking where the custom runtime system can be shared between several
bytecode executables. For embedding OCaml, I'd suggest either
1) link in -custom mode with your own main() function and the rest of
the application as C libraries or object files;
or:
2) link the Caml code in -output-obj mode and perform the final linking
(with the rest of the application) using the C linker.
Both approaches are documented in the chapter "C interface" of the
manual. I advise (2) over (1) because it's often more flexible,
e.g. you can provide the Caml parts to your Caml-phobic colleagues as
an innocuous-looking C object file, and they don't even need to have
ocamlc installed to perform the final link of the application.
> So I had to hack Larbin's
> main routine to test for the special -p single argument and then call
> only ocaml_main_init(argv); and exit(0) in that case. I believe that
> it would be quite trickly to embed Ocaml inside a significant
> application which uses the -p flag (see the code in
> ocaml/byterun/startup.c routine parse_command_line). At least I
> suggest that the linking mechanism use a less natural convention (such
> as "-print-ocaml-symbols" as argv[1] of main) and that it could be
> documented. (and I did not found quickly where Ocaml invokes this
> magic -p flag).
The ocamlc linker, when invoked with -use-runtime /my/runtime,
will invoke /my/runtime -p to learn about the primitives that
/my/runtime provides.
> Second remark: for embedding Ocaml inside Larbin I need the
> -use-runtime flag to the ocamlc compiler. But it seems that the next
> version (v3.03) does not have it anymore. I hope that it will still be
> possible to embed OCaml inside an application without having to
> compile the whole application as a shared library.
Yes, it will still be possible, for two reasons:
1) you don't need -use-runtime here (see above)
2) -use-runtime was gone in 3.03 alpha, but is back by popular demand
in the next release.
(The new facilities for dynamic loading makes -use-runtime
essentially useless, but these dynamic loading facilities are not yet
running on all systems, so let's keep -use-runtime for a while.)
> 3rd remark:
> why don't caml_main take and changes the main argc,argv arguments
> (like e.g. gtk_init routine in the Gtk toolkit) so that the
> application can use the other arguments. Otherwise, I suggest to
> publicize the parse_command_line routine so an embedding application
> could parse its own main arguments and pass some others to ocaml
> before starting the Ocaml interpreter. (imagine you want to embed
> Ocaml inside an existing Gtk application?).
I agree that only your main() routine knows how to deal with the
command-line arguments and options. So, the "argv" arguments that it
passes to caml_main are not, in general, the same "argv" that main()
received. Often, none of the arguments and options are intended for
Caml, they are all to be processed by your main program. Then,
it suffices to pass caml_main the arguments
{ argv[0], NULL }
i.e. an empty command-line. In more complicated situations, you may
have to parse the command-line, construct a "caml_argv" array of
arguments intended for Caml, and call caml_main(caml_argv), but I've
never encountered a need for doing this.
Best wishes,
- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
^ permalink raw reply [flat|nested] 2+ messages in thread