Testing plperl<->plperlu interaction
in [PgSql]
|
From: Andrew Dunstan on 8 Jan 2010 18:58 Tim Bunce wrote: > > Or perhaps put the tests that require multiplicity into a plperl_multi.sql > file and add logic to the GNUmakefile to add that file to REGRESS > if "perl -V:usemultiplicity" returns "usemultiplicity='define';" > > > OK, here is a patch that provides for running regression tests for plperlu alone and plperl/plperlu interaction, skipping the latter if it's not supported on the platform, using the test Tim has suggested. cheers andrew
From: Tom Lane on 8 Jan 2010 20:20 Andrew Dunstan <andrew(a)dunslane.net> writes: > OK, here is a patch that provides for running regression tests for > plperlu alone and plperl/plperlu interaction, skipping the latter if > it's not supported on the platform, using the test Tim has suggested. > ! ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';) > ! REGRESS += plperl_plperlu > ! endif Hm ... I wonder how badly this fails if perl isn't present? Before you say that that won't matter, consider "make clean" etc. The makefile does have to parse. It might be sufficient to wrap this test in an "ifneq ($(PERL),)" or similar. Also, some commentary connecting this test to plperl.c's support for two interpreters would be a good thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 8 Jan 2010 21:21 Tom Lane wrote: > > Hm ... I wonder how badly this fails if perl isn't present? > > Before you say that that won't matter, consider "make clean" etc. > The makefile does have to parse. > > It might be sufficient to wrap this test in an "ifneq ($(PERL),)" > or similar. > OK, can do that. > Also, some commentary connecting this test to plperl.c's support for > two interpreters would be a good thing. > > > ITYM in the .sql file(s)? I also see that I'll have to make a small adjustment in the MSVC build programs. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 8 Jan 2010 21:34 Andrew Dunstan <andrew(a)dunslane.net> writes: > Tom Lane wrote: >> Also, some commentary connecting this test to plperl.c's support for >> two interpreters would be a good thing. > ITYM in the .sql file(s)? No, the test in the makefile is what seems to need a comment. It doesn't have to be much. I was thinking something like # if Perl can support two interpreters, test plperl-and-plperlu cases ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';) BTW, what about the MSVC scripts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 8 Jan 2010 21:43 Tom Lane wrote: > Andrew Dunstan <andrew(a)dunslane.net> writes: > >> Tom Lane wrote: >> >>> Also, some commentary connecting this test to plperl.c's support for >>> two interpreters would be a good thing. >>> > > >> ITYM in the .sql file(s)? >> > > No, the test in the makefile is what seems to need a comment. It > doesn't have to be much. I was thinking something like > > # if Perl can support two interpreters, test plperl-and-plperlu cases > ifeq ($(shell $(PERL) -V:usemultiplicity), usemultiplicity='define';) > OK > BTW, what about the MSVC scripts? > Yes, I will fix vcregress.pl. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 Prev: [HACKERS] Testing plperl<->plperlu interaction Next: Hot standby documentation |