> > what really is the motivation for keeping some of the tested binaries in
> > the sourcetree when doing installcheck?
>
> As opposed to what? We're certainly not going to *install* regress.so,
> and I can't see requiring contrib to be there either. These are test
> files, not part of the ins
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> what really is the motivation for keeping some of the tested binaries in the
> sourcetree when doing installcheck?
As opposed to what? We're certainly not going to *install* regress.so,
and I can't see requiring contrib to be there either. These a
> > Would it make sense to have a standard way to run the regression tests
> > against DLL files on the *installed* system?
>
> The RPMs do this, but their solution is pretty darn ugly: ship the test
> files along with a custom Makefile (and I think they have to patch the
> test files, too). I'm
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Would it make sense to have a standard way to run the regression tests
> against DLL files on the *installed* system?
The RPMs do this, but their solution is pretty darn ugly: ship the test
files along with a custom Makefile (and I think they have to p
Hi!
When running "make installcheck", the DLL files for the regression tests
are loaded from the source tree "../../../contrib/" etc. While this
certainly makes a bit sense, it poses a problem for binary
distributions that want to run the regression tests. It also causes a
small problem for the ms
