Обсуждение: How does MSVC's fetchRegressOpts() work at all?

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=hstoreifeq ($(python_majorversion),2)REGRESS_OPTS += --load-extension=plpythonu
--load-extension=hstore_plpythonuendif

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?
        regards, tom lane

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

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

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

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