Re: Should contrib modules install .h files? - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Should contrib modules install .h files?
Date
Msg-id 87lg9oaghh.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Should contrib modules install .h files?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should contrib modules install .h files?
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> It seems like there were two separate areas of
 Tom> disagreement/questioning, one being the file layout (whether to
 Tom> add per-extension subdirectories) and then one about how one would
 Tom> actually use this, ie what would the -I switch(es) look like and
 Tom> where would they get injected.

 Tom> My impression is that there was consensus for per-extension
 Tom> subdirectories, but the usage scenario isn't totally designed yet.
 Tom> In principle, only the layout question has to be resolved to make
 Tom> it OK to ship this in v11.

Currently, everything is agnostic about the usage scenario - the
existing extension include files will work with either
-I$(includedir_server)/extension and #include "hstore/hstore.h", or with
-I$(includedir_server)/extension/hstore and #include "hstore.h".

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

What constitutes "practical"?

Right now it seems unlikely that there's much of a use case for
referring to more than two different extensions at a time (a pl and a
data type, for building a transform module outside either the pl's or
the type's source tree). Referring to one is more likely (in my case,
hstore_pllua is written to build inside pllua-ng's source tree, so all
it needs is to get at hstore.h).

-- 
Andrew (irc:RhodiumToad)


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Making "COPY partitioned_table FROM" faster
Next
From: Andrew Gierth
Date:
Subject: Re: Should contrib modules install .h files?