Re: [HACKERS] perl interface bug? - Mailing list pgsql-hackers

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