Обсуждение: Re: [COMMITTERS] pgsql: Allow pg_regress to be run outside the build tree.

Tom Lane wrote:
> petere@postgresql.org (Peter Eisentraut) writes:
>> Allow pg_regress to be run outside the build tree.  Look for input files
>> in both input and output dir, to handle vpath builds more simply.
> 
> Buildfarm doesn't like this patch much :-(.  It's definitely not working
> on the MSVC setup, and it looks like VPATH builds on Unixen aren't in
> good shape either.

vpath build should be fixed now.  MSVC will need to update the 
pg_regress call sites, but I'll leave that to those maintaining that 
build system.  In particular, the --dlpath option needs to be added.

Peter Eisentraut <peter_e@gmx.net> writes:
> vpath build should be fixed now.  MSVC will need to update the 
> pg_regress call sites, but I'll leave that to those maintaining that 
> build system.  In particular, the --dlpath option needs to be added.

contrib is still pretty broken.  One part of it is needing a --srcdir
option in pgxs.mk, which I fixed.  But some of the modules still
fail --- it looks like the problem is with the ones having data/
subdirectories.  You seem to have taken out the copying of the data
files into the vpath build tree, but I think you might have to
put it back.
        regards, tom lane

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> vpath build should be fixed now.  MSVC will need to update the 
>> pg_regress call sites, but I'll leave that to those maintaining that 
>> build system.  In particular, the --dlpath option needs to be added.
> 
> contrib is still pretty broken.  One part of it is needing a --srcdir
> option in pgxs.mk, which I fixed.  But some of the modules still
> fail --- it looks like the problem is with the ones having data/
> subdirectories.  You seem to have taken out the copying of the data
> files into the vpath build tree, but I think you might have to
> put it back.

I think the right fix would be to convert those .sql files to 
input/*.source files and have pg_regress substitute the absolute 
directory names in them, like it is done for the backend.

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> contrib is still pretty broken.  One part of it is needing a --srcdir
>> option in pgxs.mk, which I fixed.  But some of the modules still
>> fail --- it looks like the problem is with the ones having data/
>> subdirectories.  You seem to have taken out the copying of the data
>> files into the vpath build tree, but I think you might have to
>> put it back.

> I think the right fix would be to convert those .sql files to 
> input/*.source files and have pg_regress substitute the absolute 
> directory names in them, like it is done for the backend.

Ugh.  I don't think it's acceptable to make contrib modules have to do
that.  Even if we fix all the ones in core, what of other people relying
on the pgxs infrastructure?
        regards, tom lane

Tom Lane wrote:
>> I think the right fix would be to convert those .sql files to 
>> input/*.source files and have pg_regress substitute the absolute 
>> directory names in them, like it is done for the backend.
> 
> Ugh.  I don't think it's acceptable to make contrib modules have to do
> that.  Even if we fix all the ones in core, what of other people relying
> on the pgxs infrastructure?

Yeah, true.  Maybe copy the data directory over, but let pg_regress do it?

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Ugh.  I don't think it's acceptable to make contrib modules have to do
>> that.  Even if we fix all the ones in core, what of other people relying
>> on the pgxs infrastructure?

> Yeah, true.  Maybe copy the data directory over, but let pg_regress do it?

That'd be okay with me.  pg_regress already knows a lot about the
subdirectory structure it's working with, so one more thing doesn't
sound too bad.
        regards, tom lane

On 02/10 17.29, Peter Eisentraut wrote:
> Tom Lane wrote:
> >>I think the right fix would be to convert those .sql files to 
> >>input/*.source files and have pg_regress substitute the absolute 
> >>directory names in them, like it is done for the backend.
> >
> >Ugh.  I don't think it's acceptable to make contrib modules have to do
> >that.  Even if we fix all the ones in core, what of other people relying
> >on the pgxs infrastructure?
> 
> Yeah, true.  Maybe copy the data directory over, but let pg_regress do it?

For the record: when I integrated the pg_regress test suite (8.3.3)
into OpenSolaris recently, I worked around various problems by making
a wrapper script pg_regress.sh which copies everything into a
temporary directory structure and then runs pg_regress from there.

This involved creating three levels of dummy directories due to some
hardcoded "../../../" in paths.  A bit ugly, but then this package
isn't to be included in the standard distribution to end users, but
will be used by Solaris QA.

-- 
Bjorn Munch                 Sun Microsystems
Trondheim, Norway       http://sun.com/postgresql/

Is this a TODO?

---------------------------------------------------------------------------

Bjorn Munch wrote:
> On 02/10 17.29, Peter Eisentraut wrote:
> > Tom Lane wrote:
> > >>I think the right fix would be to convert those .sql files to 
> > >>input/*.source files and have pg_regress substitute the absolute 
> > >>directory names in them, like it is done for the backend.
> > >
> > >Ugh.  I don't think it's acceptable to make contrib modules have to do
> > >that.  Even if we fix all the ones in core, what of other people relying
> > >on the pgxs infrastructure?
> > 
> > Yeah, true.  Maybe copy the data directory over, but let pg_regress do it?
> 
> For the record: when I integrated the pg_regress test suite (8.3.3)
> into OpenSolaris recently, I worked around various problems by making
> a wrapper script pg_regress.sh which copies everything into a
> temporary directory structure and then runs pg_regress from there.
> 
> This involved creating three levels of dummy directories due to some
> hardcoded "../../../" in paths.  A bit ugly, but then this package
> isn't to be included in the standard distribution to end users, but
> will be used by Solaris QA.
> 
> -- 
> Bjorn Munch                 Sun Microsystems
> Trondheim, Norway       http://sun.com/postgresql/
> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +