[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libguestfs] [nbdkit PATCH] build: Install ocaml files relative to -

From: Eric Blake
Subject: Re: [Libguestfs] [nbdkit PATCH] build: Install ocaml files relative to --prefix
Date: Fri, 7 Dec 2018 16:44:53 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

[adding the automake list, in case someone has advice]

On 12/7/18 4:22 PM, Richard W.M. Jones wrote:
On Fri, Dec 07, 2018 at 03:09:43PM -0600, Eric Blake wrote:
Rather than always trying to install ocaml files into $(OCAMLLIBS),
which is likely to be root-owned and therefore fail during a
'./configure --prefix=$HOME/subdir', we instead choose to always
install relative to $(prefix) and let distro packagers take steps
post-install to move the distro's pre-built copy into the correct
location for the distro.  This fixes a 'make distcheck' failure.

Signed-off-by: Eric Blake <address@hidden>
  plugins/ocaml/ | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/ocaml/ b/plugins/ocaml/
index b95f255..bbde5e1 100644
--- a/plugins/ocaml/
+++ b/plugins/ocaml/
@@ -39,7 +39,7 @@ EXTRA_DIST = \


-ocamllibdir = $(OCAMLLIB)
+ocamllibdir = $(libdir)/ocaml
  ocamllib_DATA = NBDKit.mli NBDKit.cmi NBDKit.cmx NBDKit.o

  NBDKit.cmi: NBDKit.mli

I'm actually one of the authors of m4/ocaml.m4.  Could that file be
fixed to provide a better $(OCAMLLIB)?

No. You _can't_ change $(OCAMLLIB) directly, because it is used for more than just an installation location (I tried, and then compilation started failing when it couldn't find ocaml-specific .h files). The problem is tying ocamllibdir to $(OCAMLLIB), not $(OCAMLLIB) itself.

I suspect however the answer will be no.  Because what we're really
getting is the output of ‘ocamlc -where’.  Unfortunately if people are
using the opam package manager which installs OCaml in your home
directory then ‘ocamlc -where’ will be some directory under $HOME and
entirely unrelated to $(libdir).

Thus I think this patch won't work ...

It's a classic problem - if our package wants to install add-ins usable by a third-party, asking the third party where it was installed does NOT mean that WE can install in the same place. And most packages haven't figured out that making it easy to ask 'where should I install MY add-ons so that they can then be easily linked into your project as third-party addons' is a much different question than 'where do you load your third-party addons from'.

If it were a standard FHS location, the GNU Coding Standards might have recommended an approach of './configure --ocamldir=...', but that doesn't scale to every possible combination of packages that want to install 3rd-party modules usable by other packages.

I'm not upset if this patch doesn't go in, but if it doesn't, I'm stumped at how to get 'make distcheck' to work around the problem of skipping installation to an absolute directory outside of --prefix. Again, I think it's nicer to have './configure --prefix=$HOME/subdir; make; make install' install everything locally, and then follow up as needed with a post-install action to move (or copy/symlink/install) 3rd-party modules from there into their final useful location (creating an .rpm or .deb would be the typical place to do such scripting when building the package in a form intended to be shipped as part of a distro).

What's annoying about this is that we DO honor $(DESTDIR), which is great for working around attempts to install into a root-owned directory; but DESTDIR installs are not the same as --prefix=$HOME/user installs. Maybe if there were some way to automate a mode where anything starting with --prefix is installed normally, but anything with an absolute name is installed via DESTDIR, all on the same 'make install' run, and then check that the union of those two install locations makes sense. But that would be a new automake feature, and no telling how long it would take before packages can rely on distros shipping an automake that new.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization: |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]