On Thu, 19 Mar 2020 at 18:47, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-03-15 02:28, Craig Ringer wrote: > > On Fri, 13 Mar 2020 at 15:04, Andres Freund <and...@anarazel.de > > <mailto:and...@anarazel.de>> wrote: > > > > On 2020-03-13 14:08:12 +0800, Craig Ringer wrote: > > > 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. > > > > That, that, that's what I suggested upthread? > > > > > > Yes, and I still don't like it. "with_llvm" is the actual > > already-working option. I'd rather make this not randomly explode for > > users, but failing that we can just hack the Makefile in the rpms for > > EL-7 (where it's a particular mess) and rely on an error message for > > other cases. > > I don't really get the problem. with_llvm=no works, so it can be used. > > Options that automatically disable things based on what is installed in > the build environment are bad ideas. For instance, we on purpose don't > have configure decide anything based on whether readline is installed. > Either you select it or you don't, there is no "auto" mode. > > Fine with me. I wrote it before identifying that with_llvm=no was a viable workaround. The whole thing is a bit ugly, but if the fix isn't clearly better than the problem the fix shouldn't go in. This way it'll be searchable-for at least. I think we'll be adopting some kind of ugly workaround like this for the CentOS 7 packages in PGDG yum because they're a bit of a special case, since the llvm support requires an additional 3rd party that isn't declared as a build-depend on the devel package. But that can be done at packaging level + a small patch applied during package builds for CentOS 7 only. Withdrawn. -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise
