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