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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
