>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> The module would reference its own headers using #include "foo.h",
>> which would not find extension/module/foo.h, so no problem here.
Tom> Check, although we also need to document that you should do it
Tom> that way. Also, at least with gcc, the rule about "look in the
Tom> calling file's directory first" would prevent problems (except in
Tom> VPATH builds ... does PGXS support that? Should we recommend "-I."
Tom> before the "-I$(includedir_server)/extension" switch?)
PGXS is supposed to support VPATH builds. I do not believe -I. is
needed in the normal case, but we should probably document that if the
module uses any -I flags of its own they should normally go first.
Tom> Hm. Do we know of any extensions big enough that they need
Tom> subdirectories of headers? I don't mind leaving that for later as
Tom> long as it's not a present need somewhere. On the other hand,
Tom> couldn't it "just work" to write "x/y.h" in the list of headers to
Tom> install?
It doesn't "just work" because (a) all the existing makefile variables
that give files to install assume that any path given is the source path
only, not to be preserved in the copy; (b) we don't want to constrain
the source file layout in a way that would force .h files to be in a
specific place.
Compare the DATA variable in pgxs: DATA = foo/bar.sql means to install
$(srcdir)/foo/bar.sql as $(DESTDIR)$(datadir)/$(datamoduledir)/bar.sql,
_not_ as $(DESTDIR)$(datadir)/$(datamoduledir)/foo/bar.sql. Making
HEADERS behave otherwise would be inconsistent and inflexible.
For example, suppose my extension source dir looks like this:
./Makefile
./foo.control
./src
./src/foo.h
./src/foo1.c
./src/foo2.c
./scripts/foo--1.0.sql
I would have these in the makefile:
HEADERS = src/foo.h
DATA = scripts/foo--1.0.sql
and it seems clear to me that that should install foo.h as
$(includedir_server)/extension/foo/foo.h and not as foo/src/foo.h.
>> Making an out-of-tree build for hstore_plperl etc. work [...]
Tom> I think we'd want to press forward on making that happen, so that
Tom> hstore_plperl and friends can serve as copy-and-pasteable
Tom> prototype code for out-of-tree transform modules. Do you have an
Tom> idea how to fix the other problem you mentioned with the plpython
Tom> makefiles?
The plpython makefiles are including a makefile to munge regression
tests for python3 vs python2. The most obvious fix would be to install
this makefile as lib/pgxs/src/pl/plpython/regress-python3-mangle.mk
(I don't think any other changes would be needed).
I'll do some tests on this.
--
Andrew (irc:RhodiumToad)
