Re: TAP test breakage on MacOS X

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TAP test breakage on MacOS X
Date: 2014-10-31 04:40:37
Message-ID: 19401.1414730437@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> I took a quick look. I concur with Fabien that the dependency on
> MAKELEVEL seems pretty horrid: in particular, will that not break the
> ability to initiate "make check" from somewhere below the top directory?

Another use-case that seems to be broken both by Peter's patch and my
proposed variant is

configure ...
make ...
cd src/bin/something
hack hack hack
make
make check
ooops ... hack some more
make
make check

Neither proposed approach would result in reinstalling the updated binary
you just built into the common "temp install" tree, so the second "make
check" step would just retest the old binary.

The simplest solution that comes to mind is to define a "temp-install"
target that is the same as "make install" except it installs the stuff
built in the current directory into the "temp install" tree instead of the
configured installation target tree. You'd have to remember to do "make
temp-install" before a "make check"; but it would work, and it's not so
different from "make install" then "make installcheck", which is what you
usually do for this use-case if you've got the tree configured to install
into a throwaway installation location.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2014-10-31 04:42:40 Re: group locking: incomplete patch, just for discussion
Previous Message Tom Lane 2014-10-31 03:52:57 Re: infinite loop in _bt_getstackbuf