BUG #15414: extension compilation fails when c++ files are named with .cc

On 2018-10-01 19:46:03 +0000, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 15414
Logged by: Jerry Sievert
Email address: code@legitimatesounding.com
PostgreSQL version: 11beta4
Operating system: any
Description:

when --with-llvm is configured, compiling c++ extensions that use .cc and
not .cpp fail with no rule to create .bc files.

We currently have two rules to compile .bc files from source code:

src/Makefile.global.in

%.bc : %.c
$(COMPILE.c.bc) -o $@ $<

%.bc : %.cpp
$(COMPILE.cxx.bc) -o $@ $<

I'm a bit worried that supporting extensions that PG itself doesn't use
- and thus necessarily built by a buildsystem that's not just PGXS -
will be a, let's say iterative, process. Before v11 there wasn't a C++
integration PGXS wise, so extensions really can't be faulted for
developing their own PGXS extensions.

I guess we have two choices:
1) Add rules for ".cpp", ".cc", ".C", ".cxx", and ".c++" and whatever
else we can think of. Add additional variants whenever somebody
presents one (and backpatch it).
2) Insist that pg extensions follow PGXS rules, which atm are to use
.cpp for c++ source files.

I don't really have an opinion here.

Greetings,

Andres Freund

On 2018-10-01 13:25:48 -0700, Andres Freund wrote:

On 2018-10-01 19:46:03 +0000, PG Bug reporting form wrote:

The following bug has been logged on the website:

Bug reference: 15414
Logged by: Jerry Sievert
Email address: code@legitimatesounding.com
PostgreSQL version: 11beta4
Operating system: any
Description:

when --with-llvm is configured, compiling c++ extensions that use .cc and
not .cpp fail with no rule to create .bc files.

We currently have two rules to compile .bc files from source code:

src/Makefile.global.in

%.bc : %.c
$(COMPILE.c.bc) -o $@ $<

%.bc : %.cpp
$(COMPILE.cxx.bc) -o $@ $<

I'm a bit worried that supporting extensions that PG itself doesn't use
- and thus necessarily built by a buildsystem that's not just PGXS -
will be a, let's say iterative, process. Before v11 there wasn't a C++
integration PGXS wise, so extensions really can't be faulted for
developing their own PGXS extensions.

I guess we have two choices:
1) Add rules for ".cpp", ".cc", ".C", ".cxx", and ".c++" and whatever
else we can think of. Add additional variants whenever somebody
presents one (and backpatch it).
2) Insist that pg extensions follow PGXS rules, which atm are to use
.cpp for c++ source files.

I don't really have an opinion here.

Just to be clear, every extension can avoid that by just adding
something like:

%.bc : %.cxx
$(COMPILE.cxx.bc) -o $@ $<

To their makefile. It appears in plv8's case that additionally required
modifications to include some additional compiler flags - but that's
pretty fundamentally something we can't solve. If PGXS should know about
some compiler flags, it needs to be told via PG_CPPFLAGS et al.

- Andres

Hi, see comments inline:

On Oct 1, 2018, at 1:25 PM, Andres Freund <andres@anarazel.de> wrote:

I'm a bit worried that supporting extensions that PG itself doesn't use

Pg chose the extension .cpp, and chose it fairly recently. It seems to have been an arbitrary choice for the three files added as part of the JIT addition.

I guess we have two choices:
1) Add rules for ".cpp", ".cc", ".C", ".cxx", and ".c++" and whatever
else we can think of. Add additional variants whenever somebody
presents one (and backpatch it).

This is a rather disingenuous choice. Perhaps a better approach would be to do a quick survey of the existing c++ extensions (there aren’t very many), and make a determination of what the community has chosen to support. As an aside, .C will be problematic on filesystems that are case-insensitive.

2) Insist that pg extensions follow PGXS rules, which atm are to use
.cpp for c++ source files.

I don't really have an opinion here.

You have an obvious opinion here, and had a very strong opinion on irc.

Hi,

On 2018-10-01 13:50:19 -0700, Jerry Sievert wrote:

On Oct 1, 2018, at 1:25 PM, Andres Freund <andres@anarazel.de> wrote:

I'm a bit worried that supporting extensions that PG itself doesn't use

Pg chose the extension .cpp, and chose it fairly recently. It seems to have been an arbitrary choice for the three files added as part of the JIT addition.

Well, we had to make a choice, no?

I guess we have two choices:
1) Add rules for ".cpp", ".cc", ".C", ".cxx", and ".c++" and whatever
else we can think of. Add additional variants whenever somebody
presents one (and backpatch it).

This is a rather disingenuous choice. Perhaps a better approach would
be to do a quick survey of the existing c++ extensions (there aren’t
very many), and make a determination of what the community has chosen
to support.

I'm not following? Are you blaming me for suggesting to few, or too many
file extensions? What does make the above list disingenuous?

As an aside, .C will be problematic on filesystems that are
case-insensitive.

I don't think the existance of a %.bc: %.C rule would cause problems,
even on a case-insensitive system? Obviously it'd be problematic if
there's such files in the external project, and that project wants to
support a case-insensitive FS, but that's not really our problem as the
goal is to support outside conventions, no?

2) Insist that pg extensions follow PGXS rules, which atm are to use
.cpp for c++ source files.

I don't really have an opinion here.

You have an obvious opinion here, and had a very strong opinion on irc.

Uh, I really don't. Perhaps you should start with the assumptions that
other people aren't dealing with you in bad faith? I told you which
rule to add, helped debugging it including looking at the source code of
the extension, then suggested you report a bug so we can discuss a
potential upstream resolution with more people? The only thing I pushed
back on was that we "arbitrarily" broke stuff.

Greetings,

Andres Freund

Jerry Sievert <jerry@legitimatesounding.com> writes:

On Oct 1, 2018, at 1:25 PM, Andres Freund <andres@anarazel.de> wrote:
1) Add rules for ".cpp", ".cc", ".C", ".cxx", and ".c++" and whatever
else we can think of. Add additional variants whenever somebody
presents one (and backpatch it).

This is a rather disingenuous choice. Perhaps a better approach would be to do a quick survey of the existing c++ extensions (there aren’t very many),

Andres just named five, which is about four too many. I wouldn't mind
adding one more, but it's not very clear where to stop. Most of the ones
he mentioned do seem to have some currency, with the possible exception
of '.C' which as you say is a hazardous choice.

regards, tom lane

I'm not following? Are you blaming me for suggesting to few, or too many
file extensions? What does make the above list disingenuous?

No, you presented a straw-man argument that seems to suggest that if a change were made now, that there would be continual changes that would need to be back ported indefinitely.

I don't think the existance of a %.bc: %.C rule would cause problems,
even on a case-insensitive system? Obviously it'd be problematic if
there's such files in the external project, and that project wants to
support a case-insensitive FS, but that's not really our problem as the
goal is to support outside conventions, no?

Perhaps not, but it would be appropriate to look at the projects that have been active, in use, and part of the pg ecosystem long before decisions are made, and not just dismiss them out of hand.