Re: [HACKERS] perl interface bug?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] perl interface bug? |
Дата | |
Msg-id | 9014.908465967@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] perl interface bug? (Brook Milligan <brook@trillium.NMSU.Edu>) |
Ответы |
Re: [HACKERS] perl interface bug?
|
Список | pgsql-hackers |
Brook Milligan <brook@trillium.NMSU.Edu> writes: > We cannot kill this idea because 'make test' doesn't run without the > postmaster. After all, NONE of the regression tests do either! Edmund is thinking of a different situation. The perl5 interface is also a "Perl module", which means that it is supposed to build and install under very rigid rules --- this is supposed to work: perl Makefile.PL make make test make install If you were installing the perl5 module separately from Postgres proper, and already had a running Postgres server, that should indeed work. (With the caveat that you first have to set POSTGRES_HOME environment variable to /usr/local/pgsql or local equivalent.) It's not *entirely* clear to me that that's a very plausible scenario, since we distribute the perl5 module along with Postgres. But it does work and we probably shouldn't break it. Come to think of it, Brook's proposed changes do break the perl5 directory as a standalone Perl module, because it no longer includes a Makefile.PL, only a Makefile.PL.in. Can we avoid that by finding some other way to get the install target directory name into the perl5 makefile? Maybe, instead of being rewritten by autoconf, Makefile.PL could actively go look for the directory name, say by looking to see if ../../Makefile.global exists and contains a POSTGRESDIR= line. If not, fall back to requiring POSTGRES_HOME to be set. regards, tom lane
В списке pgsql-hackers по дате отправления: