How does MSVC's fetchRegressOpts() work at all?

On 05/18/2015 12:48 PM, Tom Lane wrote:

The MSVC members of the buildfarm seem to not like my recent patch
b14cf229f4bd7238, which basically did this to contrib/hstore_plpython's
Makefile:

SHLIB_LINK += ../hstore/libhstore.a $(wildcard ../../src/pl/plpython/libpython*.a) $(wildcard ../../src/pl/plpython/libplpython*.a)
endif

-REGRESS_OPTS = --load-extension=hstore
+REGRESS_OPTS += --load-extension=hstore
ifeq ($(python_majorversion),2)
REGRESS_OPTS += --load-extension=plpythonu --load-extension=hstore_plpythonu
endif

Now they're failing to load hstore before running the regression test, eg
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2015-05-18%2015%3A37%3A17

Looking at vcregress.pl's sub fetchRegressOpts, it seems that it only
notices "REGRESS_OPTS =" lines not "REGRESS_OPTS +=" lines, so that
isn't surprising --- but how is it that the tests *are* still loading
plpythonu and hstore_plpythonu? I grant that my Perl is weak, but
I don't see how this code would ever have dealt with either lines
using +=, or multiple assignments to REGRESS_OPTS. How come it worked
before?

relevant code:

if ($module eq "hstore_plpython" ||
$module eq "ltree_plpython")
{
die "Python not enabled in configuration"
if !defined($config->{python});

# Attempt to get python version and location.
# Assume python.exe in specified dir.
my $pythonprog = "import sys;" .
"print(str(sys.version_info[0]))";
my $prefixcmd = $config->{python}
. "\\python -c \"$pythonprog\"";
my $pyver = `$prefixcmd`;
die "Could not query for python version!\n" if $?;
chomp($pyver);
if ($pyver eq "2")
{
push @opts, "--load-extension=plpythonu";
push @opts, '--load-extension=' . $module . 'u';
}
else
{
# disable tests on python3 for now.
chdir "..";
return;
}
}

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:

On 05/18/2015 12:48 PM, Tom Lane wrote:

Looking at vcregress.pl's sub fetchRegressOpts, it seems that it only
notices "REGRESS_OPTS =" lines not "REGRESS_OPTS +=" lines, so that
isn't surprising --- but how is it that the tests *are* still loading
plpythonu and hstore_plpythonu? I grant that my Perl is weak, but
I don't see how this code would ever have dealt with either lines
using +=, or multiple assignments to REGRESS_OPTS. How come it worked
before?

relevant code:

Oh man, that's ugly.

If I were to fix fetchRegressOpts so it picks up all the makefile's
additions to REGRESS_OPTS, would we be able to eliminate that hack?
Or do we need the python-version kluge anyway?

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

I wrote:

If I were to fix fetchRegressOpts so it picks up all the makefile's
additions to REGRESS_OPTS, would we be able to eliminate that hack?
Or do we need the python-version kluge anyway?

Oh, scratch that, there's no very easy way to deal with the ifeq()
business in the makefile. So I'll just make it accept += and
things should be OK. Sure is a house of cards though.

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

On 05/18/2015 01:37 PM, Tom Lane wrote:

I wrote:

If I were to fix fetchRegressOpts so it picks up all the makefile's
additions to REGRESS_OPTS, would we be able to eliminate that hack?
Or do we need the python-version kluge anyway?

Oh, scratch that, there's no very easy way to deal with the ifeq()
business in the makefile. So I'll just make it accept += and
things should be OK. Sure is a house of cards though.

It's far from the only such hack.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers