[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 <eblake(a)redhat.com>
> ---
> 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