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

[Eric Blake]

[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/Makefile.am | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/plugins/ocaml/Makefile.am b/plugins/ocaml/Makefile.am
> > index b95f255..bbde5e1 100644
> > --- a/plugins/ocaml/Makefile.am
> > +++ b/plugins/ocaml/Makefile.am
> > @@ -39,7 +39,7 @@ EXTRA_DIST = \
> >
> >   if HAVE_OCAML
> >
> > -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:  qemu.org | libvirt.org