agora inbox for [email protected]  

help / color / mirror / Atom feed

From: Jim Nasby <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Pg Hackers <[email protected]>
Subject: Re: Very confusing installcheck behavior with PGXS
Date: Thu, 7 Jan 2016 09:24:07 -0600
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CA+TgmoaKJFjY-=A6x3Qhk2Sf7egQG3=FdSUdzTCQtogYbBGyCQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>

On 1/7/16 9:12 AM, Tom Lane wrote:
> Jim Nasby <[email protected]> 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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

view thread (19+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Very confusing installcheck behavior with PGXS
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox