Обсуждение: BUG #15414: extension compilation fails when c++ files are named with.cc
BUG #15414: extension compilation fails when c++ files are named with.cc
От
PG Bug reporting form
Дата:
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.