Обсуждение: ccache is required by postgresql12-devel RPM

Hello.

# I'm not sure -hakcers is the place for this, though..

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?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

On Thu, Jan 30, 2020 at 08:36:17PM +0900, Kyotaro Horiguchi wrote:
> Hello.
> 
> # I'm not sure -hakcers is the place for this, though..
> 
> 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?

    https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

CC'ing Devrim.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

Bruce Momjian <bruce@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

At Sat, 07 Mar 2020 13:41:58 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> Bruce Momjian <bruce@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?

Maybe and 10, 11 have the same configuration. For clarity, my
objective is just to know whether it is deliberate or not.

> 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.

I don't remember how I configured development environments both with
CentOS7/8 but both of them initially didn't have ccache.  And I'm not
the only one who stumbled on the CLANG setting. But we might be a
small minority..

> 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.

Although I'm not sure we should path-ify tool chains on building
extensions, if the -devel package doesn't work without ccache, the
package needs to depend on ccache package. But such a policy creates
many bothersome dependency on every tool.  I'm not sure how to deal
with that...

So, I'm satisfied to know it is the intended behavior.

Thank you for the explanation, Tom.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center