At Thu, 12 Mar 2020 14:08:31 +0800, Craig Ringer <cr...@2ndquadrant.com> wrote in > On Thu, 12 Mar 2020 at 03:43, Andres Freund <and...@anarazel.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