Detection of IPC::Run presence in SSL TAP tests
Hi all,
001_ssltests.pl in src/test/ssl/ includes the following to skip all
tests should IPC::Run be not available:
# Like TestLib.pm, we use IPC::Run
BEGIN
{
eval {
require IPC::Run;
import IPC::Run qw(run start);
1;
} or do
{
plan skip_all => "IPC::Run not available";
}
}
In all the other tests or modules we don't bother about such a thing
as prove_check only works if --enable-tap-test is used, and we get a
hard failure anyway if trying to run the TAP tests with the configure
switch but without IPC::Run installed. Heikki, this looks like
unnecessary crafting to me, no? prove_check being enforced in
Makefile.global already gives enough guarantee.
Thanks,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
001_ssltests.pl in src/test/ssl/ includes the following to skip all
tests should IPC::Run be not available:
...
In all the other tests or modules we don't bother about such a thing
as prove_check only works if --enable-tap-test is used, and we get a
hard failure anyway if trying to run the TAP tests with the configure
switch but without IPC::Run installed. Heikki, this looks like
unnecessary crafting to me, no? prove_check being enforced in
Makefile.global already gives enough guarantee.
Certainly, it's pointless to have a defense only here. And I know very
well that make check falls over in an ugly, hard-to-interpret-if-you've-
not-seen-it-before fashion if you do --enable-tap-tests and don't have
IPC::Run installed.
I'd vote for removing this and adding a configure-time check that
insists on IPC::Run when --enable-tap-tests is given.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jun 13, 2017 at 11:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Certainly, it's pointless to have a defense only here. And I know very
well that make check falls over in an ugly, hard-to-interpret-if-you've-
not-seen-it-before fashion if you do --enable-tap-tests and don't have
IPC::Run installed.I'd vote for removing this and adding a configure-time check that
insists on IPC::Run when --enable-tap-tests is given.
There was a patch last year to do something like that:
/messages/by-id/56BDDC20.9020506@postgrespro.ru
While Test::More is part of any standard installation, IPC::Run is
not. FWIW, I still think that this is worth checking for. That's way
better than having the TAP tests explode with a weird fatal failure
where one needs to dig into the logs just to find out that the module
is missing.
Attached is an updated patch, with credit mainly going to Eugene
Kazakov. I have run autoconf myself, I know that usually committers do
that... Hope you don't mind.
--
Michael
Attachments:
configure-tap-modules-v3.patchapplication/octet-stream; name=configure-tap-modules-v3.patchDownload+158-13
On 6/13/17 03:49, Michael Paquier wrote:
001_ssltests.pl in src/test/ssl/ includes the following to skip all
tests should IPC::Run be not available:
We used to have stanzas like that elsewhere but then removed them in
favor of the configure option. It looks like this was forgotten. I
have committed a change to just remove it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
On Tue, Jun 13, 2017 at 11:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'd vote for removing this and adding a configure-time check that
insists on IPC::Run when --enable-tap-tests is given.
There was a patch last year to do something like that:
/messages/by-id/56BDDC20.9020506@postgrespro.ru
While Test::More is part of any standard installation, IPC::Run is
not. FWIW, I still think that this is worth checking for. That's way
better than having the TAP tests explode with a weird fatal failure
where one needs to dig into the logs just to find out that the module
is missing.
Attached is an updated patch, with credit mainly going to Eugene
Kazakov. I have run autoconf myself, I know that usually committers do
that... Hope you don't mind.
Pushed, thanks. I grabbed the very latest copy of ax_prog_perl_modules
out of the GNU archives --- it's only cosmetically different, but we
might as well be au courant.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 6/15/17 15:57, Tom Lane wrote:
Pushed, thanks. I grabbed the very latest copy of ax_prog_perl_modules
out of the GNU archives --- it's only cosmetically different, but we
might as well be au courant.
Um, this patch was previously rejected. Shouldn't we at least discuss
it, or have it go through the commit fest? This is not a regression
against 9.6.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
On 6/15/17 15:57, Tom Lane wrote:
Pushed, thanks. I grabbed the very latest copy of ax_prog_perl_modules
out of the GNU archives --- it's only cosmetically different, but we
might as well be au courant.
Um, this patch was previously rejected. Shouldn't we at least discuss
it, or have it go through the commit fest? This is not a regression
against 9.6.
It was rejected only because we didn't want to move the goalposts for
the then-active CMake effort. That argument no longer applies, I'd say.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers