On 2014-10-30 20:13:53 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-10-30 19:53:54 -0400, Tom Lane wrote:
> >> Well, for example, you don't have and don't want to install IPC::Run.
>
> > Well, that's what the hypothetical configure test is for. I see little
> > reason in this specific case to do anything more complicated than check
> > for prove and IPC::Run in configure and use them if necessary.
>
> 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.
We e.g. detect compiler support for certain features that result in
possible speedups and/or better warnings. we detect wether bison is
available...
> 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?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services