Re: Should contrib modules install .h files?
От | Andrew Gierth |
---|---|
Тема | Re: Should contrib modules install .h files? |
Дата | |
Msg-id | 87lg9oaghh.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: Should contrib modules install .h files? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Should contrib modules install .h files?
|
Список | 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 по дате отправления: