Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dbrRX-0003dQ-D0 for pgsql-hackers@arkaria.postgresql.org; Sun, 30 Jul 2017 16:51:51 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dbrRW-0003MN-Vw for pgsql-hackers@arkaria.postgresql.org; Sun, 30 Jul 2017 16:51:51 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dbrQ0-0000du-AW for pgsql-hackers@postgresql.org; Sun, 30 Jul 2017 16:50:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dbrPx-0000ma-Nb for pgsql-hackers@postgresql.org; Sun, 30 Jul 2017 16:50:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v6UGoAI7025938; Sun, 30 Jul 2017 12:50:10 -0400 From: Tom Lane To: Noah Misch cc: Andrew Dunstan , pgsql-hackers@postgresql.org Subject: Re: PL_stashcache, or, what's our minimum Perl version? In-reply-to: <20170730163054.GA2630977@rfd.leadboat.com> References: <20540.1501210115@sss.pgh.pa.us> <16894.1501392088@sss.pgh.pa.us> <20170730154814.GA2636941@rfd.leadboat.com> <22744.1501430710@sss.pgh.pa.us> <20170730163054.GA2630977@rfd.leadboat.com> Comments: In-reply-to Noah Misch message dated "Sun, 30 Jul 2017 09:30:54 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25936.1501433410.1@sss.pgh.pa.us> Date: Sun, 30 Jul 2017 12:50:10 -0400 Message-ID: <25937.1501433410@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Noah Misch writes: > On Sun, Jul 30, 2017 at 12:05:10PM -0400, Tom Lane wrote: >> Well, OK, but I'd still like to tweak configure so that it records >> an absolute path for prove rather than just setting PROVE=prove. >> That way you'd at least be able to tell from the configure log >> whether you are possibly at risk. > That's an improvement. The reason it does that seems to be that we use AC_CHECK_PROGS rather than AC_PATH_PROGS for locating "prove". I can see no particular consistency to the decisions made in configure.in about which to use: AC_CHECK_PROGS(GCOV, gcov) AC_CHECK_PROGS(LCOV, lcov) AC_CHECK_PROGS(GENHTML, genhtml) AC_CHECK_PROGS(DTRACE, dtrace) AC_CHECK_PROGS(XML2_CONFIG, xml2-config) AC_CHECK_PROGS(DBTOEPUB, dbtoepub) AC_CHECK_PROGS(XMLLINT, xmllint) AC_CHECK_PROGS(XSLTPROC, xsltproc) AC_CHECK_PROGS(OSX, [osx sgml2xml sx]) AC_CHECK_PROGS(FOP, fop) AC_CHECK_PROGS(PROVE, prove) versus AC_PATH_PROG(TAR, tar) PGAC_PATH_BISON PGAC_PATH_FLEX PGAC_PATH_PERL PGAC_PATH_PYTHON AC_PATH_PROG(ZIC, zic) PGAC_PATH_TCLCONFIGSH([$with_tclconfig]) I'm tempted to propose that we switch *all* of these uses of AC_CHECK_PROGS to AC_PATH_PROGS. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers