Re: Should contrib modules install .h files?

>>>>> "Andres" == Andres Freund <andres@anarazel.de> writes:

 >> Sure, it works for the simple cases like hstore, but how does it
 >> handle the case of a pgxs extension that installs more than one
 >> include file, one of which includes another?

 Andres> I might be momentarily daft (just was on a conference call for
 Andres> a while ;)), but why'd that be problematic? The header files
 Andres> can just specify the full path, and they'll find each other
 Andres> because of the aforementioned -I?

The #includes in the header files need to work both for the module's own
build, and also for building modules depending on it.

So existing practice would be that the module's own source dir (for
module "foo") would look something like:

./Makefile
./foo.h    (contains #include "foo_2.h")
./foo_2.h
./foo.c    (contains #include "foo.h")

and eventually foo.h and foo_int.h get installed as
$(includedir_server)/extension/foo/foo.h and /foo_2.h

To make this work with Tom's scheme means changing the directory layout
of the original module. For contrib modules it's easy because the "." in
the above paths is already "contrib/foo", but for PGXS the module should
not be making assumptions about the name of its build dir, so you end up
having to rejig the layout to something like

./Makefile
./foo
./foo/foo.h (contains #include "foo/foo_2.h")
./foo/foo_2.h
./foo.c  (contains #include "foo/foo.h", compiled with -I$(srcdir))

or

./Makefile
./include/foo
./include/foo/foo.h
./include/foo/foo_2.h
./foo.c  (compiled with -I$(srcdir)/include)

Either way, it's a forced change to the PGXS module's file layout if it
wants to install headers that work for other people using Tom's
suggested approach. I'm not on board with this unless there's a better
solution than I've seen so far.

-- 
Andrew (irc:RhodiumToad)