Обсуждение: BUG #15414: extension compilation fails when c++ files are named with.cc

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.

.cc is a fairly standard c++ file ending, and has been in use by a popular
pg extension for 7 years.  pg should be able to understand this file ending,
and not fail when trying to compile them against pg11 with llvm configured.

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
filesadded 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,
.Cwill 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
filesadded 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
continualchanges 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
ecosystemlong before decisions are made, and not just dismiss them out of hand.