Обсуждение: tsearch2 regression test path problem

The makefile for tsearch2 has this rule:

tsearch2.sql: tsearch.sql.in   sed -e 's,MODULE_PATHNAME,$$libdir/$(MODULE_big),g' \       -e
's,DATA_PATH,$(datadir)/contrib,g'$< >$@
 


The problem is that on Windows, $(datadir) is typically a virtual Msys 
path (or least typically it is for me) which is not understood by a 
running backend, so when it goes to load the file with "make 
installcheck" it can't find it.

I'm not sure if there is some nicely portable way around this. Any 
suggestions?

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> The problem is that on Windows, $(datadir) is typically a virtual Msys 
> path (or least typically it is for me) which is not understood by a 
> running backend,

Huh?  Explain that in English please ... because I would think that what
you are suggesting the behavior is would break a lot more things than
just tsearch2.
        regards, tom lane

Andrew Dunstan <andrew@dunslane.net> writes:
> I'm not sure if there is some nicely portable way around this. Any 
> suggestions?

Now that I think about it, we already had an open issue with tsearch2,
which is that the way it's doing this, a relocatable installation is
impossible.

I think the most reasonable fix is to change the readstoplist() function
so that it will accept relative paths and interpret them as relative to
the "share" directory (which is $datadir as seen by the Makefiles; we
can get the correct runtime location from get_share_path).  Then we can
just put "contrib/english.stop" into the pg_ts_dict entry and not have
to interpolate any build-time path at all.

Will see about doing this.
        regards, tom lane

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>The problem is that on Windows, $(datadir) is typically a virtual Msys 
>>path (or least typically it is for me) which is not understood by a 
>>running backend,
>>    
>>
>
>Huh?  Explain that in English please ... because I would think that what
>you are suggesting the behavior is would break a lot more things than
>just tsearch2.
>
>
>  
>

It does not, at least for me.  In fact I spent many hours a few months 
ago making sure that we could run make check from Msys, despite the 
dual-set-of-paths - see the changes to pg_regress.sh that were made 
around then.

In fact, of the whole gamut of checks my buildfarm script runs (make 
check, make installcheck, and contrib's make installcheck), this is the 
*only* failure due to a path problem.

cheers

andrew

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>I'm not sure if there is some nicely portable way around this. Any 
>>suggestions?
>>    
>>
>
>Now that I think about it, we already had an open issue with tsearch2,
>which is that the way it's doing this, a relocatable installation is
>impossible.
>
>I think the most reasonable fix is to change the readstoplist() function
>so that it will accept relative paths and interpret them as relative to
>the "share" directory (which is $datadir as seen by the Makefiles; we
>can get the correct runtime location from get_share_path).  Then we can
>just put "contrib/english.stop" into the pg_ts_dict entry and not have
>to interpolate any build-time path at all.
>
>Will see about doing this.
>
>
>  
>

Excellent.

cheers

andrew