>>>>> "Andres" == Andres Freund <and...@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)
