Re: Getting mod_caml and perl4caml into Debian

[Richard Jones <rich@annexia.org>]

On Sat, Nov 01, 2003 at 08:19:09PM +0100, Sven Luther wrote:
> Read the ocaml_packaging_policy document in /usr/share/doc/ocaml.
> 
> The correct way of doing this is to build depend on ocaml-3.07 and
> depend on ocaml-base-3.07 for the runtime library and ocaml-3.07 for the
> -dev library.

OK, I think I've done this correctly now. New packages here:

http://www.annexia.org/tmp/modcaml-src/

> > Not really sure which files need to go in the plain package, and which
> > in the -dev package, and whether it is worth having a separate
> 
> Well the -dev is for the development stuff, while the plain package is
> the runtime package, what is needed to run modcaml built binaries. In
> normal packages with C bindings you put the dll.so in there only, but in
> your case you may need to put more stuff, apache related stuff maybe ?

I've now split it like this:

In plain package:
	mod_caml.so, mod_caml_executable    (the Apache module)
	dbi*.cmo, dbi*.o, dbi*.cmx, META    (see below)
	/usr/lib/mod_caml                   (run-time support)

In -dev package:
	*.mli, *.cmi files
	documentation
	examples

Is this OK?

> > Haven't fixed the native version so this would build correctly on
> > platforms without ocamlopt. Note that mod_caml doesn't ordinarily use
> > native executables, the reason being that it uses Dynlink for
> > everything and Dynlink only supports bytecode. However I do build /
> > use the Dbi modules separately, and so those are compiled natively for
> > now.
> 
> Ok, ...
> 
> Maybe you could post a small description on how your package is exactly
> to be used, especially the interaction with apache, and i can give you
> more advanced help on these topics.

Right, so this is quite complicated :-) But I'll try to explain as
best I can.

mod_caml.so is an Apache module which gets loaded into Apache using
ordinary dynamic library loading (ie. dlopen, etc.). It contains the
full OCaml interpreter, plus the bytecode for the support modules like
Apache, Cgi, Cgi.Template, Dbi, Dbi_postgres, Dbi_mysql, Mod_caml and
so on.

Mod_caml "programs" are .cmo files which depend upon, but do not
include, the support modules. They are loaded into the OCaml
interpreter using Dynlink. Because the basic OCaml interpreter in
mod_caml.so is linked with the support modules already, Dynlink can
successfully load them.

Some of the support modules are "viable" for use outside mod_caml, and
some really only make sense within mod_caml.so:

- Apache: You can only make Apache API calls from within an Apache
  module, so it makes absolutely no sense for this module to be
  separate from mod_caml.so.

- Cgi, etc: These modules depend intimately on Apache, so again it
  would make no sense to create a standalone program which used this
  library.

- Mod_caml: Contains initialization code, and also depends on Apache.

- Dbi, Dbi_*: Database API, very viable outside mod_caml.so. In fact
  I'm using it in other programs right now.

Eventually I want to spin off the Dbi code into a separate package.

About bytecode vs. native:

Dynlink doesn't support the concept of loading native code *.cmx
files. Hence all parts of mod_caml.so are bytecode only.

However the Dbi modules can be used in external programs, and so I
compile bytecode and native versions of these.

I hope that makes sense.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://freshmeat.net/users/rwmj
Merjis Ltd. http://www.merjis.com/ - all your business data are belong to you.
"My karma ran over your dogma"