Subject: Re: Very confusing installcheck behavior with PGXS
To: Tom Lane <tgl@sss.pgh.pa.us>
References: <56899F36.9000607@BlueTreble.com>
 <CA+TgmoaKJFjY-=A6x3Qhk2Sf7egQG3=FdSUdzTCQtogYbBGyCQ@mail.gmail.com>
 <5651.1452102882@sss.pgh.pa.us> <568E7829.2050805@BlueTreble.com>
 <12108.1452178021@sss.pgh.pa.us> <568E7B4A.4080003@BlueTreble.com>
 <13036.1452179541@sss.pgh.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>, Robert Haas <robertmhaas@gmail.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
Message-ID: <568E8317.3000806@BlueTreble.com>
Date: Thu, 7 Jan 2016 09:24:07 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <13036.1452179541@sss.pgh.pa.us>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: bluetreble.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2016 15:24:12.2851 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR11MB0678
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 1/7/16 9:12 AM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 1/7/16 8:47 AM, Tom Lane wrote:
>>> That's pretty hard to believe.  There's nothing in pg_regress that looks
>>> in places other than the given --inputdir.
>
>> Actually, I think it does... from pg_regress_main.c:
>
>> 	/*
>> 	 * Look for files in the output dir first, consistent with a vpath search.
>> 	 * This is mainly to create more reasonable error messages if the file is
>> 	 * not found.  It also allows local test overrides when running pg_regress
>> 	 * outside of the source tree.
>> 	 */
>> 	snprintf(infile, sizeof(infile), "%s/sql/%s.sql",
>> 			 outputdir, testname);
>> 	if (!file_exists(infile))
>> 		snprintf(infile, sizeof(infile), "%s/sql/%s.sql",
>> 				 inputdir, testname);
>
> Oh, I'd just been looking in pg_regress.c.
>
> The comment's argument about "more reasonable error messages" seems pretty
> dubious to me.  The real reason for this behavior seems to have been to
> simplify VPATH builds --- see commit feae7856, which added this code,
> and was able to get rid of quite a lot of makefile cruft.
>
> I think though that doing it exactly like this is a bit klugy.  A better
> implementation of VPATH would've been to introduce an optional "secondary
> input directory" into which we look if we fail to find something in the
> main input directory.  Then we'd run it with main input directory in the
> build tree and secondary input directory pointing to the source tree.

Seems reasonable. Sounds like a good beginner project to boot. :)

> (I'm also wondering how convert_sourcefiles() works at all in a vpath
> build, considering that I don't see it doing anything like this ...)

It's only looking at outputdir, which I suspect is never ambiguous.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers