Re: TAP test breakage on MacOS X

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TAP test breakage on MacOS X
Date: 2014-10-31 01:03:43
Message-ID: 14819.1414717423@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
>> As I said upthread, that approach seems to me to be contrary to the
>> project policy about how configure should behave.

> I don't think that holds much water. There's a fair amount of things
> that configure detects automatically. I don't think the comparison to
> plperl or such is meaningful - that's a runtime/install time
> difference. These tests are not.

Meh. Right now, it's easy to dismiss these tests as unimportant,
figuring that they play little part in whether the completed build
is reliable. But that may not always be true. If they do become
a significant part of our test arsenal, silently omitting them will
not be cool for configure to do.

We think that it's okay to autoconfigure things like which semaphore
technology to use in part because we believe we can test the results.
I think if someone asks for "make check-world", it should be pretty
deterministic what that means.

Historical note: I was not originally very much on board with the strict
enable-what-you-want policy for configure behavior, but I got religion
after working at Red Hat for awhile. Nondeterministic package build
behaviors *suck*. Here's one example:
https://bugzilla.redhat.com/show_bug.cgi?id=427063

>> If you have selected
>> (or, someday, defaulted to) --enable-tap-tests, configure should *fail*
>> if you don't have the tools to run the tests. Not silently disable tests
>> that we have decided are valuable. How exactly would that be different
>> from silently omitting readline support if we don't find that library?

> Because it doesn't result in a user visible regression?

Uncaught bugs become user-visible regressions.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-10-31 01:09:04 Re: how to handle missing "prove"
Previous Message Michael Paquier 2014-10-31 00:27:35 Re: Review of Refactoring code for sync node detection