RE: New unified regression test driver

This may sound stupid, but what's wrong with including a binary make
executable in a binary PostgreSQL package? It could be stored in the
regression test directory and then you could write a "standard" regression
test makefile instead of a different "script" for each platform. A compiler
would be out of the question due to its size, but a binary make shouldn't be
too large.

Fred Reimer
Eclipsys Corporation

> -----Original Message-----
> From: pgsql-hackers-owner(at)hub(dot)org
> [mailto:pgsql-hackers-owner(at)hub(dot)org]On
> Behalf Of Peter Eisentraut
> Sent: Thursday, October 05, 2000 1:43 PM
> To: Lamar Owen
> Cc: PostgreSQL Development
> Subject: Re: [HACKERS] New unified regression test driver
>
>
> Lamar Owen writes:
>
> > That said, I have a request -- since the binary distributions might
> > possibly be installed on machines with no make and no
> compiler, I would
> > like to see the regression tests be reduced to a simple script and
> > driver that could be simply invoked with no need for make.
> Binary-only
> > users might want to regress a little, too.
>
> This was originally one of my implementation goals, but it's
> a bit tricky.
> Some of the SQL input files contains absolute paths as part of CREATE
> FUNCTION or COPY commands. We'd have to patch up these paths
> as part of
> the installation run. That's terribly inelegant and it would probably
> break something else I'm thinking about. (Automatically generating
> install manifests by substituting something clever for the
> $(INSTALL) make
> variable. You might be interested in this too. Stay tuned.)
>
> That said, the new script should make things a bit easier for
> you because
> it is reasonably standalone, allows parallel and serial
> regression tests,
> and has command line options to find the input and output
> files. The ugly
> details about how to install the right files I would like to
> leave up to
> the packager right now.
>
> One thing I thought of was that perhaps the regression test
> driver could
> substitute the correct paths at run time rather than at build
> time. But
> that would break backward compatibility with the old drivers,
> and as we
> haven't even settled on the new one yet, it's probably an
> inopportune time
> to try it now.
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/
>
>