Re: Should contrib modules install .h files?

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Should contrib modules install .h files?
Дата
Msg-id dc5ad1a1-be01-ea26-1bb1-a6313cc0fffd@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Should contrib modules install .h files?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Should contrib modules install .h files?  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: Should contrib modules install .h files?  (Andres Freund <andres@anarazel.de>)
Re: Should contrib modules install .h files?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 23.07.18 06:15, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> On Sun, Jul 22, 2018 at 09:42:08PM -0400, Stephen Frost wrote:
>>> So, +1 from me for having a directory for each extension.
> 
>> So, like Stephen, that's a +1 from me.
> 
> Same here.  One-file-per-extension is too strongly biased to tiny
> extensions (like most of our contrib examples).

Nobody said anything about one-file-per-extension.  You can of course
have hstore_this.h and hstore_that.h or if you want to have many, use
postgis/this.h and postgis/that.h.  That's how every C package in the
world works.  We don't need to legislate further here other than, use
sensible naming.

Also, let's recall that the point of this exercise is that you want to
install the header files so that you can build things (another
extension) that somehow interacts with those extensions.  Then, even if
you put things in separate directories per extension, you still need to
make sure that all the installed header files don't clash, since you'll
be adding the -I options of several of them.  In a way, doing it this
way will make things less robust, since it will appear to give extension
authors license to use generic header names.

> I don't have a real strong opinion on whether it's too late to
> push this into v11.  I do not think it'd break anything other than
> packagers' lists of files to be installed ... but it does seem
> like a new feature, and we're past feature freeze.

Certainly a new feature.  I suggest submitting it to the next commit fest.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Remove psql's -W option
Следующее
От: Andres Freund
Дата:
Сообщение: Re: How can we submit code patches that implement our (pending)patents?