On 2014-10-30 21:03:43 -0400, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
