caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Xavier Leroy <xavier.leroy@inria.fr>
To: Basile STARYNKEVITCH <basile@starynkevitch.net>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] embedding Ocaml in an existing application
Date: Sat, 8 Dec 2001 17:09:06 +0100	[thread overview]
Message-ID: <20011208170906.B4455@pauillac.inria.fr> (raw)
In-Reply-To: <15375.58084.611097.762861@hector.lesours>; from basile@starynkevitch.net on Thu, Dec 06, 2001 at 10:28:04PM +0100

> 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


      reply	other threads:[~2001-12-08 16:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-06 21:28 Basile STARYNKEVITCH
2001-12-08 16:09 ` Xavier Leroy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20011208170906.B4455@pauillac.inria.fr \
    --to=xavier.leroy@inria.fr \
    --cc=basile@starynkevitch.net \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).