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
