Re: Should contrib modules install .h files?
От | Andres Freund |
---|---|
Тема | Re: Should contrib modules install .h files? |
Дата | |
Msg-id | 20180723155530.r5r72i2xtcs2d5fj@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Should contrib modules install .h files? (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Список | pgsql-hackers |
On 2018-07-23 17:22:16 +0200, Peter Eisentraut wrote: > 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. PGXS provides a certain way of doing things. It's far from insane for us to procscribe that we go for $extension/. I fail to see any sort of advantage of using $extension_$header.h. It only serves to create additional work. > 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. I'd suggest just using the name with the $extension/ prefix going forward. > > 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. Given that there seems to be fairly widespread agreement, anyone that commented but you, and the patch has been reviewed, I see zero reason to wait for the next CF for a committer's patch. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: