Re: [HACKERS] perl interface bug?
От | Edmund Mergl |
---|---|
Тема | Re: [HACKERS] perl interface bug? |
Дата | |
Msg-id | 3626728A.53C6099C@bawue.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] perl interface bug? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] perl interface bug?
|
Список | pgsql-hackers |
Brook Milligan wrote: > > 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 > > Ok, I see now. So, we need the following: > > - a Makefile.PL that works out of the box for the above sequence, > given that POSTGRES_HOME is set properly. > > - a Makefile.PL that works with the Postgres installation and gets the > right shared library, so if we run `make test' later (or use the > interface in any way) it works immediately upon Postgres > installation. > let's forget about the make test. In order to get the right libpq.so it should be sufficient to change the Makefile in the interfaces directory in a way, that 'make' and 'make install' for perl5 is called after 'make install' in libpq. Of course I would have to adapt Makefile.PL in order to use pgsql/lib instead of pgsql/src/interfaces/libpq as linkpath for libpq.so. But: for 'make install' in the perl directory, you need to be root, because the perl installation usually is owned by root. How do you want to solve this problem ? Those people without root access can say 'perl Makefile.PL PREFIX=/my/perl_directory' to install the module into a private directory. Again this is not possible with a hard coded 'perl Makefile'. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de Im Haldenhau 9 http://www.bawue.de/~mergl 70565 Stuttgart fon: +49 711 747503 Germany
В списке pgsql-hackers по дате отправления: