NAME

       dh_ocaml - calculates OCaml packages dependencies and provides

SYNOPSIS

       dh_ocaml [debhelper options]
                   [--runtime-map=dev:runtime,...]
                   [--nodefined-map=dev:ignore1,ignore2]
                   [--checksum=str]

DESCRIPTION

       dh_ocaml is a debhelper program that is responsible for filling the ${ocaml:Provides} and
       ${ocaml:Depends} substitutions and adding them to substvars files.

       dh_ocaml acts on three kinds of binary packages: those shipping development part of OCaml
       libraries (usually named libXXX-ocaml-dev or libXXXX-camlp4-dev), those shipping runtime
       for OCaml libraries (e.g. plugin and shared library, usually named libXXX-ocaml or
       libXXXX-camlp4) and those shipping OCaml bytecode non-custom executables (i.e.
       executables interpreted by /usr/bin/ocamlrun).

       On specific packages the convention is XXX for development and XXX-base for runtime (e.g.
       ocaml and ocaml-base).

       On OCaml library packages dh_ocaml will firstly look at OCaml objects shipped by the
       package. Then, dh_ocaml uses appropriate program on them for collecting information about
       OCaml modules defined and used by them. Information about defined units will be used to
       automatically create the OCaml md5sums registry entry for development and runtime package,
       e.g.  /var/lib/ocaml/md5sums/libXXX-ocaml-dev.md5sums. Information about imported units
       will instead be used as keys in the OCaml md5sums registry for retrieving dependency
       information for the package. Those information will then be used to fill the
       ${ocaml:Depends} substvars. They will also be used to fill the ${ocaml:Provides} substvar
       which will be replaced by a name of the form libXXX-ocaml-dev-NNNN, where NNNN is an
       checksum computed from the interfaces of the modules provided by the library.

       Object files (*.cm[ioax], *.cmx[as]) and executables are processed by ocamlobjinfo(1), if
       possible.

       Dependencies extracted from the system md5sum registry, dh_ocaml will add in
       ${ocaml:Depends}:

       1.  dependency from libXXX-ocaml-dev to libXXX-ocaml (runtime part of the library), if
           there is a libXXX-ocaml package in debian/control;

       2.  dependency from libXXX-ocaml-dev to the appropriate libYYYY-ocaml-dev-NNNN packages;

       3.  dependency from libXXX-ocaml to the appropriate libYYYY-ocaml-NNNN packages.

       4.  dependency from XXXX to the appropriate libYYYY-ocaml-NNNN packages.

       For runtime package ${ocaml:Provides} will be set libXXXX-ocaml-NNNN and for development
       package to libXXX-ocaml-dev-NNNN.

       The same kind of relations are established between libXXXX-camlp4 and libXXXX-camlp4-dev
       packages.

OPTIONS

       --checksum str
           Checksum are automatically computed from exported interface by the dev/runtime
           package. This checksum can only show a partial information about the interface.  In
           this case the checksum computation can be replaced by another string which gives more
           information about dependencies.

           Typically, ocaml/ocaml-base package doesn't use a computed checksum but the version of
           OCaml.

       --nodefined-map dev1:unit1,unit2,...
           Ignore some exported unit of package/runtime dev1. This option should be used with
           care. It is a very special case, when one library ship a drop-in replacement for
           another library. Most of the time if one library ship the same unit it should be
           considered as an error.

           This option can be repeated as much as needed to define ignore for all development
           packages.

       --runtime-map dev1:runtime1:checksum1,dev2:runtime2:checksum2,...
           The association between development part of libraries and their runtimes is guessed by
           dh_ocaml according to the OCaml packaging policy. Thus, libXXX-ocaml-dev is the name
           of the package shipping the development part of XXX library while libXXX-ocaml, if
           any, is the name of the package shipping the corresponding runtime. libXXXX-camlp4-dev
           and libXXXX-camlp4 packages are handled the same way.

           Using --runtime-map you could override the pairs development package name, runtime
           package name. The value passed to --runtime-map admits no spaces and must be a comma
           separated list of items. Each item can be a single package name (stating that that
           name corresponds to the development part of a library), two package names separated by
           a colon (stating that the first corresponds to the development part of a library,
           while the second to its accompanying runtime part) or two package names separated by a
           colon, followed by a colon and a checksum (which will be used as checksum for the
           package pair).

           Every package that doesn't follow libXXX-ocaml-dev/libXXX-ocaml,
           libXXXX-camlp4-dev/libXXXX-camlp4 or which is not defined in the runtime map are
           considered to be binary package and will be searched only for bytecode.

FILES

       debian/libXXX-ocaml-dev.olist debian/libXXX-camlp4-dev.olist
           By default, the list of OCaml objects or bytecode binaries shipped by your package
           which should be analyzed for retrieving dependency information is guessed by dh_ocaml.

           This file permits one to specify a file which lists, one per line, that OCaml objects
           or bytecode binaries. Objects should be in one of the format understandable by
           ocamlobjinfo(1). Files are considered relative to the package build directory.

CONFORMS TO

       Debian policy, version 3.7.2

       OCaml packaging policy, version 1.0.0

SEE ALSO

       ocamlobjinfo(1), debhelper(7), ocaml-md5sums(1)

       This program is a part of debhelper.

AUTHORS

       Stefano Zacchiroli <zack@debian.org>, Samuel Mimram <smimram@debian.org>, Mehdi Dogguy
       <mehdi@debian.org>, Sylvain Le Gall <gildor@debian.org>, Stephane Glondu
       <glondu@debian.org>