Proposal ocaml guidelines
Hans de Goede
j.w.r.degoede at hhs.nl
Wed May 2 19:03:35 UTC 2007
I got looking into this because of these review requests:
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are:
Which are PLD resp debian ocaml guidelines. And they seem to agree on most things.
Notice that I've exactly 0 experience in packaging or writing caml software,
this is all based on common sense and my observations with the 3 packages above.
OCaml modules / libs should be named ocaml-foo. (This does not apply to
applications written in caml). Rationale: this is how they are named in other
distros (Debian, PLD) and this is consistent with perl / php / python.
OCaml software can either be byte compiled, in which case it will need the
ocaml runtime and besides the runtime only the files installed by libs /
modules under /usr/lib/ocaml/stublibs (the ocaml byte code from libs gets
staticly linked into the bytecode-"executable"_.
Or they can be compiled to native code in which case all caml specific libs /
bindings get staticly linked into the executable (wrapped libraries themself
will still be dynamicly linked, but the wrapper code is linked staticly into
the executable, this can not be changed).
Thus for ocaml modules / lib(wrapper)s, in the case of byte compiled ocaml
programs only the files under /usr/lib/ocaml/stublibs from the module/lib are
needed, and to run a compiled program nothing from the module/lib is needed.
So only the files under /usr/lib/ocaml/stublibs should be in the mainpackage,
and if there are no such files (in case of a pure caml module / lib) then the
mainpackage should have an empty %files. All other files should go in a -devel
package as they are only needed to compile and no to run ocaml programs.
This is taken from:
Following files should NOT be distributed:
- *.cmo object files. There is however one exception -- if file is needed for
link (like gtkInit.cmo in lablgtk or std_exit.cmo in OCaml itself), then it
should be of course included.
- *.o for corresponding *.cmx. They are included in *.a anyway. Exception -- as
- *.ml sources.
- *.mli interface sources. However, if package lacks any documentation (which
is unfortunately often the case), you can include *.mli, but it should be
gziped and placed in package as %doc.
More information about the fedora-devel-list