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

At Thu, 12 Mar 2020 14:08:31 +0800, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote in
> On Thu, 12 Mar 2020 at 03:43, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > On 2020-03-11 11:25:28 +0800, Craig Ringer wrote:
> > > I propose that per the attached patch PGXS should simply skip adding
> > > the automatic dependency for .bc files if clang cannot be found.
> > > Extensions may still choose to explicitly declare the rule in their
> > > own Makefile if they want to force bitcode generation.
> >
> > Hm, that seems like it could also cause silent failures (e.g. after a
> > package upgrade or such).
> >
> > How about erroring out, but with an instruction that llvm can be
> > disabled with make NO_LLVM=1 or such?
>
> I thought about that at first, but that'll only benefit people who're
> hand-compiling things, and it's already possible with
>
> make with_llvm=no ...
>
> The proportion of people hand-compiling is an ever-shrinking
> proportion of the user base. When something's nested inside an rpm
> specfile inside a docker container inside a bash script inside another
> Docker container on an AWS instance .... not so fun. They might be
> able to inject it into the environment. But often not.
>
> Extensions that explicitly must generate bytecode may add their own
> dependency rule. Or we could make skipping bytecode generation if llvm
> cannot be found at build-time something the extension can turn off
> with a PGXS option, as suggested upthread.

FWIW, the patch makes bitcode generation skipped (almost silently)
when clang is installed but ccache is not, with -devel packages for
CentOS8. Counldn't we make the bitcode generation a separate make
target, at least for PGXS build? Rather than turning it on and off by
the condition which doens't seem having a clear relation with the
necessity of bitcode generation?

> I'm reluctant to go with anything that requires each existing
> extension to be patched because that introduces a huge lag time for
> this change to actually help anyone out.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center