Re: Should contrib modules install .h files?

[ back to this after a detour to ON CONFLICT land ]

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> OK, after considerable experiment I think I can answer these points: the
> most "practical" way is to do this (or an equivalent), as you originally
> suggested:
> PG_CPPFLAGS = -I$(includedir_server)/extension

Yeah, that's where I thought we'd end up.

> We could add a mention of this to the PGXS docs and the header comment
> of pgxs.mk as being the recommended practice; would that be enough?
> Or should the logic go into the pgxs makefile as suggested below?

My thought is just to document how to do this. It'll still be true that
most extensions have no dependencies on other extensions, so they won't
need any such headers; sticking extra -I switches into their builds by
default can only cause trouble.

> Tom> Something that copes with selecting the right headers if you're
> Tom> rebuilding a module whose headers are already installed (as you
> Tom> mentioned upthread).

> The module would reference its own headers using #include "foo.h",
> which would not find extension/module/foo.h, so no problem here.

Check, although we also need to document that you should do it that
way. Also, at least with gcc, the rule about "look in the calling
file's directory first" would prevent problems (except in VPATH builds
... does PGXS support that? Should we recommend "-I." before the
"-I$(includedir_server)/extension" switch?)

> One case that doesn't "just work" would be what PostGIS currently does.
> Like other extensions it doesn't (afaik) currently try and install any
> PG-related header files, but if it was modified to do so, some changes
> in those header files would be needed because a lot of them have things
> like #include "../postgis_config.h" which would fail.

Yeah, I don't doubt that extensions will have to make minor mods to
adapt to this scheme. As long as they're minor, I don't think it's
a problem.

> Another case that doesn't "just work" would be if some extension has a
> file foo.h that does #include "x/y.h" to include another file that's
> part of the same extension, expecting to get extension/foo/x/y.h. Right
> now, the install rule I added to the pgxs makefile puts all header files
> for a module in the same dir; if we wanted to support making a whole
> subdirectory tree under extension/modulename, then that'd require more
> work in the makefiles.

Hm. Do we know of any extensions big enough that they need subdirectories
of headers? I don't mind leaving that for later as long as it's not a
present need somewhere. On the other hand, couldn't it "just work" to
write "x/y.h" in the list of headers to install?

> Making an out-of-tree build for hstore_plperl etc. work under this
> scheme would require changes. The in-tree build has this:
> PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl -I$(top_srcdir)/contrib/hstore
> #include "hstore.h"
> This would have to be:
> PG_CPPFLAGS = -I$(top_srcdir)/src/pl/plperl -I$(top_srcdir)/contrib
> #include "hstore/hstore.h"
> for the in-tree build, and
> PG_CPPFLAGS = -I$(includedir_server)/extension
> #include "hstore/hstore.h"
> for the out-of-tree build.

> This logic could perhaps be best moved into the pgxs makefile itself,
> either unconditionally adding -I options to CPPFLAGS, or conditionally
> adding them based on a WANT_EXTENSION_HEADERS flag of some sort set by
> the module makefile.

I think we'd want to press forward on making that happen, so that
hstore_plperl and friends can serve as copy-and-pasteable prototype
code for out-of-tree transform modules. Do you have an idea how to
fix the other problem you mentioned with the plpython makefiles?

regards, tom lane