use DUNE_LIBDIR environent variable

[madroach]

This helps me solve the following problem when porting for OpenBSD:

The OCaml libdir on OpenBSD is /usr/local/lib/ocaml.
When creating binary packages the installation is made into a "fake"
root, which results in a libdir like
/usr/ports/pobj/dune-1.10.0/fake-amd64/usr/local/lib/ocaml
which is constructed from PREFIX and DESTDIR:
${DESTDIR}/${TRUEPREFIX}/lib/ocaml

Now, since the pre-dune era, we set OCAMLFIND_DESTDIR to
/usr/local/lib/ocaml when building a port, but to
/usr/ports/pobj/dune-1.10.0/fake-amd64/usr/local/lib/ocaml
when (fake-)installing a port. This is not exactly how a DESTDIR is supposed to
work, but it did the job.

Now dune actually respects DESTDIR and will prepend it to
OCAMLFIND_DESTDIR, which will then result in
/usr/ports/pobj/dune-1.10.0/fake-amd64/usr/ports/pobj/dune-1.10.0/fake-amd64/usr/local/lib/ocaml
during (fake-)installation, which is obviously not what I want.

To solve this I currently need to special treat all ports using dune and
unset OCAMLFIND_DESTDIR for them.

For me it would be convenient if I could directly configure dune by
environment variables and bypass ocamlfind completely.

This commit accomplishes this only for dune install. It would be nice if
dune would respect DUNE_LIBDIR for dune build, too.

This may be related to #1707.

Here's GNU's definition of DESTDIR, LIBDIR, PREFIX and so on:
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html

[ghost]

This commit accomplishes this only for dune install. It would be nice if
dune would respect DUNE_LIBDIR for dune build, too.

Would that mean looking up installed libraries in $DUNE_LIBDIR?

Regarding the name of the variable, is there something more standard already? Such as just LIBDIR. /cc @glondu @rwmjones

[rwmjones]

Fedora has libdir as /usr/lib64. However since there is no ./configure in dune this is not passed. (Normally we'd do ./configure --libdir=/usr/lib64 amongst other things).

The deeper problem in Fedora is we can't use make install at all because it requires opam-installer, but that has a circular dependency on dune. Instead we install everything by hand.

You can see how the build/install is done:
https://src.fedoraproject.org/rpms/ocaml-dune/blob/master/f/ocaml-dune.spec#_80

[madroach]

This commit accomplishes this only for dune install. It would be nice if
dune would respect DUNE_LIBDIR for dune build, too.

Would that mean looking up installed libraries in $DUNE_LIBDIR?

Exactly!

Regarding the name of the variable, is there something more standard already? Such as just LIBDIR. /cc @glondu @rwmjones

LIBDIR is usually something like /usr/local/lib. I want DUNE_LIBDIR to be OCaml specific, in my case /usr/local/lib/ocaml.

But now that you ask, why doesn't dune simply do
/usr/local/bin/ocamlc -config |sed -ne 's/standard_library: //p'
to get the libdir in absence of findlib and opam?

The documented behaviour seems to be arbitrary:

otherwise, take the directory where ocamlc was found, and append ../lib to it. For instance if ocamlc is found in /usr/bin, use /usr/lib

If you know where ocamlc is you can call it and ask for the location of the stdlib. This is a better guess for LIBDIR than just doing ../lib

[ghost]

You are right that this behaviour is completely arbitrary! I did that because I didn't know what the standard was. I'd welcome the opinion of the experts here :) /cc @bobot who looked at this as well in the past.

@rwmjones dune actually has a configure script and it accepts --libdir :) It's just optional. If you use it, then dune will have a hardcoded library path. If you don't use it, then dune will auto-detect the library search path at runtime. Calling ./configure --libidr=... makes the produced dune binary less relocatable, however it should be fine for distributions.

Regarding opam-installer, it's no longer needed since dune 1.0.0 :) Dune is able to perform installation itself since 1.0.0.

[rwmjones]

Thanks, I've created a Fedora bug to track changes in packaging: https://bugzilla.redhat.com/show_bug.cgi?id=1740196

[madroach]

The --libdir configure option solves this issue for me. I tried this earlier, but failed to pass it properly from the ports system to the configure script. Nevermind.

[ghost]

Ok. Do you still need this PR then?

[madroach]

no, sorry for the noise.

[ghost]

No worries, useful things came out of it :)

[rwmjones]

No I don't need it either :-)