Thread
-
Re: [HACKERS] perl interface bug?
Edmund Mergl <e.mergl@bawue.de> — 1998-10-16T10:40:55Z
Brook Milligan wrote: > > > 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. > > I don't think we need to give up on make test. Either the installer > already has postgresql installed and running (in which case the > standard perl procedure with POSTGRES_HOME set will work) or he/she > doesn't and is doing this as part of the main postgresql > installation. In that case we just repeat the build after libpq is > installed; no problem. > > 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'. > > This is a complication. Perhaps to be solved secondarily. For my > information so I can think about solutions, in your command what > exactly is PREFIX pointing to? Directly to the root of the perl > library tree? > > Would a solution be to enhance the --with-perl option to point to the > directory of interest unless configure is run by root? In that case > the interfaces/Makefile could include the prefix argument if > necessary and things would just work. If one does the perl stuff > standalone, they can always issue the command with a prefix > themselves. > > Let's get the rest of this done right first, though and worry about > this root/nonroot install problem next. I goofed my earlier patches, > so I'll resubmit them and go from there. > > Cheers, > Brook the standard path for installing perl modules is .../lib/perl5/site_perl/... Only in case someone has no root access and no possibility to make a private perl installation, he will use the PREFIX option. The disadvantage of installing a module in a private directory is, in every perl script using this module the user will have to add the searchpath, so that perl is able to find the module at this non-standard place. Obviously this is only a work-around and should not be used unless the user has no root access and the user is forced to use the perl installation of the sys-admin. I guess in 95% the user/sys-admin will have to install the perl-module manually, which means - cd-ing into interfaces/perl5 - make install What's the big difference to: - cd-ing into interfaces/perl5 - perl Makefile.PL - make - make install In other words, I still prefer the solution not to build the perl module together with postgresql. I think it is sufficient to mention the perl module and the commands needed in order to install it in the INSTALL file and that's it. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de Im Haldenhau 9 http://www.bawue.de/~mergl 70565 Stuttgart fon: +49 711 747503 Germany