Bruce Momjian <br...@momjian.us> writes:
> On Thu, Jan 30, 2020 at 08:36:17PM +0900, Kyotaro Horiguchi wrote:
>> I notieced that the official PG12-devel RPM pacakge for RHEL8 mandates
>> ccache being installed on building of an extension.
>>
>> $ grep ccache /usr/pgsql-12/lib/pgxs/src/Makefile.global
>> CLANG = /usr/lib64/ccache/clang
>> # ccache loses .gcno files
>>
>> However it can be changed by explicitly setting CLANG, it seems that
>> that setting is by accident since gcc is not ccachi'fied. Anyway, I'm
>> not sure but, I think that that decision should be left with extension
>> developers. Is it intentional?
> That certainly seems wrong. Is it this URL?
I can't get too excited about this. ccache has been part of the standard
development environment on Red Hat systems for at least a decade, and thus
/usr/lib64/ccache has been in the standard PATH setting for just as long.
Devrim would have to go out of his way to force CLANG to not show up that
way in the configure result, and I don't see that it would be an
improvement for any real-world usage of the RPM results.
The core reason why it shows up that way is that llvm.m4 uses
PGAC_PATH_PROGS to set CLANG, while we don't forcibly path-ify
the CC setting. But arguably the latter is a bug, not the former.
I recall that there's been some discussion about how it'd be safer
if configure made sure that all the tool names it records are fully
path-ified.
regards, tom lane
