Re: Should contrib modules install .h files?
От | Andrew Gierth |
---|---|
Тема | Re: Should contrib modules install .h files? |
Дата | |
Msg-id | 87k1p48w2i.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Should contrib modules install .h files? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
>>>>> "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)
В списке pgsql-hackers по дате отправления: