Horton

Thread

Commits

  1. Make configure check for IPC::Run when --enable-tap-tests is specified.

  1. Detection of IPC::Run presence in SSL TAP tests

    Michael Paquier <michael.paquier@gmail.com> — 2017-06-13T07:49:41Z

    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

  2. Re: Detection of IPC::Run presence in SSL TAP tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-06-13T14:14:18Z

    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

  3. Re: Detection of IPC::Run presence in SSL TAP tests

    Michael Paquier <michael.paquier@gmail.com> — 2017-06-14T03:46:21Z

    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

  4. Re: Detection of IPC::Run presence in SSL TAP tests

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-06-15T13:24:36Z

    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

  5. Re: Detection of IPC::Run presence in SSL TAP tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-06-15T19:57:44Z

    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

  6. Re: Detection of IPC::Run presence in SSL TAP tests

    Peter Eisentraut <peter.eisentraut@2ndquadrant.com> — 2017-06-15T20:17:17Z

    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

  7. Re: Detection of IPC::Run presence in SSL TAP tests

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-06-15T20:46:41Z

    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