Re: TAP test breakage on MacOS X

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