Re: Should contrib modules install .h files?

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> On the other hand, if there's no very practical way to use the
Tom> per-extension subdirectory layout,

>> What constitutes "practical"?

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

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?

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.

No additional constraints apply to the module's own source layout
as long as foo.h, if it includes say foo_2.h, does so as
#include "foo_2.h" (if that's not in the same subdir as foo.h, the
module's own build would need to supply -I options accordingly - no
change here).

Tom> Something that copes with different modules installing headers
Tom> with the same base name.

A client of two modules foo and bar can under this scheme do

#include "foo/x.h"
#include "bar/x.h"

and it will reference the correct files; however, if both x.h files
use conflicting symbols for their multiple-inclusion guards, then they
can't both be included in the same source file without explicit #undef
hacks (but this is really an unrelated problem)

Internally to foo and bar, they would both do #include "x.h"

If both foo/x.h and bar/x.h contain #include "y.h", then that will
resolve to extension/foo/y.h in the first case and extension/bar/y.h in
the second case under the "look in the directory of the including file
first" rule.

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.

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.

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.

--
Andrew (irc:RhodiumToad)