From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: how to handle missing "prove" |
Date: | 2014-10-31 01:09:04 |
Message-ID: | 14935.1414717744@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On 10/28/14 10:01 PM, Peter Eisentraut wrote:
>> On 10/28/14 9:16 PM, Tom Lane wrote:
>>> ISTM that the project policy for external components like this has been
>>> "don't rely on them unless user says to use them, in which case fail if
>>> they aren't present". So perhaps what we ought to have is a configure
>>> switch along the lines of "--enable-tap-tests". If you don't specify it,
>>> prove_check expands to nothing. If you do specify it, we fail if we
>>> lack any of the expected support, both "prove" and whatever the agreed-on
>>> set of Perl modules is.
>> That's also a good idea.
> Here is a patch.
Looks generally reasonable, but I thought you were planning to choose a
different option name?
One minor nitpick: perhaps the --help description of the option should
read
+ --enable-tap-tests enable TAP tests (requires Perl and IPC::Run)
because in practice it'll be much more likely that people will be missing
IPC::Run than that they'll be missing Perl altogether.
Also, shouldn't we have it fail rather than just skipping tests if
IPC::Run is missing?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-10-31 01:17:41 | Re: TAP test breakage on MacOS X |
Previous Message | Tom Lane | 2014-10-31 01:03:43 | Re: TAP test breakage on MacOS X |