Is there an easy way to tell opam or dune that a library dependency is installed in a non-standard location?

Community
,
1

Hello,

I am thinking about opam packages which rely on some system-wide installation
of a dependency.

E.g. nlopt-ocaml relies on nlopt being installed in the right place.

Is there a way to support easily the case where the required dependency
has been user-installed (so in user-space), instead of system-wide?

We need a way to tell dune where the header files (.h) are located, we also
need a way to tell where the compiled library is (.so).

At runtime, I know that setting LD_LIBRARY_PATH does the right thing.
But, I am annoyed at compile time.

Thanks,
F.

2

Hello,

I recently updated a private opam package of mine, which is a C++ library binding.

In order to solve precisely this issue:

  1. I generated a conf-mylibrary opam package locally

    In one directory, I have conf-mylibrary.opam:

    • I forgot to, but I think that it should contain: flags: [ conf ]
    • build: is calling one script which generates conf-mylibrary.config file which looks like this:
opam-version: "2.0"
variables {
  mylib_inc: "<path to the include dir>"
  mylib_lib: "<path to the lib dir>"
  ...

  1. I’m installing this package with the following incantation: opam pin add conf-mylibrary . -k path -y

  2. In my wrapper package

    • in the package opam file, I have: substs: [ "<path to some dune file>"]

    • in the relevant dune.in file, I have:

      (flags (:standard -I%{conf-mylibrary:mylib_inc}%)))

    • I have only dune.in file in the source: dune it’s generated by opam, or I can do it manually: opam config subst <path to the expected dune>

opam var --package <name> displays the variables of one package.

One can also ask opam for one specific variable. By instance opam var conf-mylibrary:mylib_inc.

I borrowed this mechanism from clangml package.

Best regards

1 Like
3

That’s some pretty heavy stuff w/ a very strong dune taste.

Wouldn’t it be more easier if the package w/ the bindings could use some env. variables that the user would have setup properly?
e.g. SOMELIB_INCLUDE_DIR and SOMELIB_LIBRARY_PATH
The first one would be to find where the header files are, the second one for finding the actual library file (.so or .a).
Maybe, we could also use a third env. var: SOMELIB_ROOT, if that’s also needed.

4

That’s some pretty heavy stuff w/ a very strong dune taste.

You mentioned dune first ;-).

Yes, that’s heavy. I’m using this because it’s private work, and I do not come back to it often: I always forget all the details. Having a conf-mylibrary package, which I update only from time to time is enough for me. I just run build my wrapper without thinking about it.