Re: Very confusing installcheck behavior with PGXS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Very confusing installcheck behavior with PGXS
Date: 2016-01-07 15:12:21
Message-ID: 13036.1452179541@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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.

(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 ...)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-01-07 15:12:23 Re: checkpointer continuous flushing
Previous Message Fabien COELHO 2016-01-07 15:05:32 Re: checkpointer continuous flushing