On 2014-10-30 21:03:43 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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.
Well, I'm all for erroring out if somebody passed --enable-foo-tests and
the prerequisites aren't there. What I *am* against is requiring an
explicit flag to enable them because then they'll just not be run in
enough environments. And that's what's much more likely to cause
unnoticed bugs.
> 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
Sure, but that's about a difference that's meaningful once the
package/software is installed.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services