[opam-devel] Globally-installed OPAM Packages?

PALI Gabor Janos pgj at elte.hu
Thu Sep 5 18:39:24 BST 2013

[cross-posting for both Mirage and OPAM developers]
Hi there,

I am working on a FreeBSD/amd64 kernel module backend for Mirage, which
requires a dedicated cross-compiler due to some special requirements on the
generated code.  One of the consequences of those requirements that the
compiler cannot create ELF binaries for some of the dependent packages or
the unit tests fail.  This is fine, as binaries are usually not needed,
only the libraries.

Hence I have started to submit changes to the package maintainers, like
in case of dyntype [1].  However, Anil suggested to generalize this into
the concept of "no executables" which is basically an environment variable
which, when set, implies disabling building binaries for the given package.
This could be then set for the Mirage/kFreeBSD cross-compiler so no binaries
are built in that case.

However, there are some packages, for it would need binaries still in order
to be able to work.  An example of this is mirari [2], the Mirage build tool.
Anil recommended to use mirari of the host system instead, but the problem
is that mirari (and executables for OPAM packages, in general, I think) can
only be installed per toolchain.  That is, even if I install mirari with the
standard compiler, it becomes hidden once I switch back to the Mirage/kFreeBSD
cross-compiler to build the rest of the packages.

Apparently a host mirari cannot be installed on the system globally, unless
it is compiled from the sources manually, probably.  (Mirari is not available
as a binary package on FreeBSD unlike the OCaml compiler or OPAM.)  I cannot
build and install mirari to some global location either, as other packages,
e.g. mirage-www, depend on it as a package.

Are there any (non-hackish) solutions for this issue in the OPAM world? 

[1] https://github.com/mirage/dyntype/pull/4
[2] http://opam.ocamlpro.com/pkg/mirari.0.9.7.html

More information about the opam-devel mailing list