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
