From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Cédric Villemain <cedric(at)2ndquadrant(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Remove useless USE_PGXS support in contrib |
Date: | 2013-06-15 11:12:04 |
Message-ID: | 51BC4C04.9030307@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/15/2013 06:24 AM, Cédric Villemain wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> a écrit :
>
>> On 06/14/2013 08:35 AM, Peter Eisentraut wrote:
>>> On 6/13/13 9:20 PM, amul sul wrote:
>>>> Agree, only if we consider these contrib module is always gonna
>> deployed with the postgresql.
>>>> But, what if user going to install such module elsewhere i.e. not
> >from contrib directory of pg source.
>>> Why would anyone do that?
>>>
>>>
>> Maybe they wouldn't.
>>
>> I do think we need to make sure that we have at least buildfarm
>> coverage
>> of pgxs module building and testing. I have some coverage of a few
>> extensions I have written, which exercise that, so maybe that will
>> suffice. If not, maybe we need to have one module that only builds via
>> pgxs and is build after an install (i.e. not via the standard contrib
>> build).
> I agree, I found very useful to have all the provided extensions build with PGXS to debug it.
> It also offers a good set of natural regression tests.
>
>> I don't really like the directory layout we use for these modules
>> anyway, so I'm not sure they constitute best practice for extension
>> builders. Lately I have been using an extension skeleton that looks
>> something like this:
>>
>> License
>> Readme.md
>> META.json (for pgxn)
>> extension.control
>> Makefile
>> doc/extension.md (soft linked to ../Readme.md)
> This makes mandatory to have a MODULEDIR defined or a rule to rename it with the extension name suffixed.
Of course, for extension foo this would actually be foo.md. It installs
just fine like that. The makefile template has:
DOCS = $(wildcard doc/*.md)
>
>> src/extension.c
>> sql/extension.sql
> It is (was) the default place for regression tests....I am not sure it is a good thing to shuffle that.
> Also, you don't do 'c/source.c'
>
The sql here is the sql to install the extension, not part of the build
nor part of the tests.
Some time ago I fixed pg_regress to honor --inputdir and --outputdir
properly, so my Makefile template has this:
REGRESS_OPTS = --inputdir=test --outputdir=test \
--load-extension=$(EXTENSION)
...
override pg_regress_clean_files = test/results/
test/regression.diffs test/regression.out tmp_check/ log/
That keeps the testing stuff out of the way quite nicely.
You might not like this pattern, but I find it much saner that what we
currently use. I certainly don't claim it's perfect.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2013-06-15 11:25:49 | Re: pluggable compression support |
Previous Message | Hannu Krosing | 2013-06-15 11:11:47 | Re: pluggable compression support |