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.