Re: [PATCH] Skip llvm bytecode generation if LLVM is missing

On Fri, 13 Mar 2020 at 04:35, Andres Freund <andres(at)anarazel(dot)de> wrote:

>
> IMO only if the packager screwed up. The dependencies of the package
> that includes pgxs, headers should have the dependencies to llvm. Which
> e.g. debian's does:
>

Yes, I agree that the underlying issue is mainly with packaging.

This proposal came out of chasing down some packaging problems relating to
the EL-7 -devel packages for Pg 11 and 12, per linked mails in initial
post. They don't declare a runtime dependency on llvm toolset or clang, so
they're basically broken given the way we assume the presence of those
tools.

But

(a) do we really want to force everyone to pull in clang and the llvm
toolset when they install the -devel pkg, even if they don't install or
need the postgresqlNN-llvmjit package?
(b) EL-7 doesn't have a usable llvm/clang version even in EPEL, you have to
add a separate SCL LLVM toolset repo. So adding a dependency on
llvm-toolset into EL-7's postgresql11-devel and postgresql12-devel is most
undesirable, especially in a point release, as it'll make lots of stuff
explode messily.

I learned (b) the hard way. Don't do that.

If the consensus is that this is a packaging issue, (a) is fine, and we
should just quit whining and install a suitable clang/llvm, I'll cope with
that. I'll ask yum-packagers to patch Makefile.global for EL-7 with a
workaround like the one proposed here and for newer RH where a suitable
LLVM is available, just declare it as a dependency of the -devel pkg going
forward then make lots of noise about the change.

But the problem is that even for newer RH "enterprise" distros LLVM/clang
live in EPEL, and IIRC we don't presently require any dependencies from
EPEL to install the base postgresqlNN-* packages (except llvmjit). So we'd
be making EPEL a new repo dependency for the -devel pkg and that's not
something I'm too fond of doing in a minor release.

The alternative would be to detect a missing clang and emit a much more
informative error than the current one that explicitly suggests retrying
with

make with_llvm=no

or setting with_llvm=no in the environment.

The whole thing is a mess caused by this "enterprise-y" repository split
between core and "extras" and I'm rather frustrated by the whole thing, but
the current situation isn't much fun for users.

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise