Thread: [HACKERS] 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
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
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: https://www.postgresql.org/message-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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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: > https://www.postgresql.org/message-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
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
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