I am having problems getting the perl interface to work (but see below
for a fix).  If I install postgresql on a bare system (i.e., one with
no previous postgresql installed), the perl interface gets installed,
but the test.pl script fails with an undefined symbol error (libpq
cannot be found).  However, if I rebuild the perl interface AFTER
postgresql (actually, I think libpq is all that is necessary here) is
installed, the test.pl script works fine.

It seems that the installation procedure should be the following:

   - build postgresql (including the perl interface)
   - install postgresql, particularly libpq
   - rebuild the perl interface
   - reinstall the perl interface

The following patches accomplish the following:

- change interfaces/Makefile to reflect the order above by doing a
  make clean in perl5 before installing the perl interface; this
  forces a rebuild after libpq has been installed.  Note that
  perl-makefile-dep is no longer required under this scheme.

- create Makefile.PL.in for perl5 so that the installed path for libpq
  (as determined by configure) can be incorporated into the ld path
  when the perl interface library is built.

- fix configure.in to create Makefile.PL from Makefile.PL.in

NOTE:  rerun autoconf

NOTE:  delete interfaces/perl5/Makefile.PL

Cheers,
Brook

===========================================================================
--- interfaces/Makefile.orig	Wed Oct  7 01:00:23 1998
+++ interfaces/Makefile	Tue Oct 13 16:29:16 1998
@@ -15,13 +15,11 @@
 include $(SRCDIR)/Makefile.global
 
 
-perl-makefile-dep :=
-ifeq ($(USE_PERL), true)
-  perl-makefile-dep := perl5/Makefile
-endif
+PERL_CLEAN := DO_NOTHING
+install: PERL_CLEAN := clean
 
 
-.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
+.DEFAULT all install clean dep depend distclean:
 	$(MAKE) -C libpq $@
 	$(MAKE) -C ecpg $@
 ifeq ($(HAVE_Cplusplus), true)
@@ -33,6 +31,8 @@
 	$(MAKE) -C libpgtcl $@
 endif
 ifeq ($(USE_PERL), true)
+	-$(MAKE) -C perl5 $(PERL_CLEAN)
+	$(MAKE) perl5/Makefile
 	$(MAKE) -C perl5 $@
 endif
 ifeq ($(USE_ODBC), true)
===========================================================================
--- interfaces/perl5/Makefile.PL.in.orig	Mon Oct 12 16:25:23 1998
+++ interfaces/perl5/Makefile.PL.in	Mon Oct 12 16:25:00 1998
@@ -0,0 +1,68 @@
+#-------------------------------------------------------
+#
+# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
+#
+# Copyright (c) 1997, 1998  Edmund Mergl
+#
+#-------------------------------------------------------
+
+use ExtUtils::MakeMaker;
+use Config;
+use strict;
+
+# because the perl5 interface is always contained in the source tree,
+# we can be sure about the location of the include files and libs.
+# For development and testing we still test for POSTGRES_HOME.
+#
+#print "\nConfiguring Pg\n";
+#print "Remember to actually read the README file !\n";
+#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
+#
+#if (! $ENV{POSTGRES_HOME}) {
+#    warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
+#    foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres /home/postgres /opt/postgres)) {
+#        if (-d "$_/lib") {
+#            $ENV{POSTGRES_HOME} = $_;
+#            last;
+#        }
+#    }
+#}
+#
+#if (-d "$ENV{POSTGRES_HOME}/lib") {
+#    print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
+#} else {
+#    die "Unable to determine PostgreSQL\n";
+#}
+
+my %opts;
+
+if (! $ENV{POSTGRES_HOME}) {
+
+    my $cwd = `pwd`;
+    chop $cwd;
+
+    %opts = (
+        NAME         => 'Pg',
+        VERSION_FROM => 'Pg.pm',
+        INC          => "-I$cwd/../libpq -I$cwd/../../include",
+        OBJECT       => "Pg\$(OBJ_EXT)",
+        LIBS         => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
+    );
+
+} else {
+
+    %opts = (
+        NAME         => 'Pg',
+        VERSION_FROM => 'Pg.pm',
+        INC          => "-I$ENV{POSTGRES_HOME}/include",
+        OBJECT       => "Pg\$(OBJ_EXT)",
+        LIBS         => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
+    );
+}
+
+
+WriteMakefile(%opts);
+
+exit(0);
+
+# end of Makefile.PL
===========================================================================
--- configure.in.orig	Mon Oct 12 01:00:20 1998
+++ configure.in	Mon Oct 12 16:26:35 1998
@@ -959,6 +961,7 @@
 	interfaces/libpgtcl/Makefile
 	interfaces/odbc/GNUmakefile
 	interfaces/odbc/Makefile.global
+	interfaces/perl5/Makefile.PL
 	pl/plpgsql/src/Makefile
 	pl/plpgsql/src/mklang.sql
 	pl/tcl/mkMakefile.tcldefs.sh

Wed, 14 Oct 1998 10:55:38 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
perl interface bug?
Brook Milligan <brook@trillium.NMSU.Edu> writes:
> I am having problems getting the perl interface to work (but see below
> for a fix).  If I install postgresql on a bare system (i.e., one with
> no previous postgresql installed), the perl interface gets installed,
> but the test.pl script fails with an undefined symbol error (libpq
> cannot be found).  However, if I rebuild the perl interface AFTER
> postgresql (actually, I think libpq is all that is necessary here) is
> installed, the test.pl script works fine.

This is a longstanding problem in the Perl module.  It's fairly closely
related to the recent flamefest about LD_LIBRARY_PATH, btw --- the
trouble is that if shared lib A refers to shared lib B, then lib A may
need to contain a hardwired path to lib B.  At least on some platforms.
I think your intended fix of rebuilding the Perl shared lib after libpq
has been installed might solve the problem nicely for these platforms.

HPUX is one of the places where there's a problem, so I'll try out your
fix as soon as I get a chance.

If this flies, we should rip out the commented-out cruft in
perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME
environment variable...

			regards, tom lane

Wed, 14 Oct 1998 17:14:47 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] perl interface bug? 
   Brook Milligan <brook@trillium.NMSU.Edu> writes:
   > I am having problems getting the perl interface to work (but see below
   > for a fix).  If I install postgresql on a bare system (i.e., one with
   > no previous postgresql installed), the perl interface gets installed,
   > but the test.pl script fails with an undefined symbol error (libpq
   > cannot be found).  However, if I rebuild the perl interface AFTER
   > postgresql (actually, I think libpq is all that is necessary here) is
   > installed, the test.pl script works fine.

   This is a longstanding problem in the Perl module.  It's fairly closely
   related to the recent flamefest about LD_LIBRARY_PATH, btw --- the
   trouble is that if shared lib A refers to shared lib B, then lib A may
   need to contain a hardwired path to lib B.  At least on some platforms.
   I think your intended fix of rebuilding the Perl shared lib after libpq
   has been installed might solve the problem nicely for these platforms.

Yes, that seems to be the problem, though I don't quite recognize why
libpgtcl works (it has the same libpgtcl refers to libpq feature, but
I tried it quite awhile ago with pgaccess and all was fine).  Perhaps
there is a subtle difference between the ld command for it and the
once constructed for perl.

I chose this approach (i.e., make clean, rebuild perl stuff after
install) because I didn't want to gut the automatic perl Makefile.PL
stuff, which I don't understand completely.  To me this seemed like a
fairly clean solution, but anything better from the perl wizards is
welcome.

   HPUX is one of the places where there's a problem, so I'll try out your
   fix as soon as I get a chance.

Please let me know how it works.  I'd like to see this fixed in 6.4
since it will remove a substantial bug in the perl interface.

   If this flies, we should rip out the commented-out cruft in
   perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME
   environment variable...

Absolutely.  That stuff really isn't necessary, I don't think.  I just
didn't want to trash the file so dramatically. :)

Cheers,
Brook

Wed, 14 Oct 1998 16:07:25 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] perl interface bug?
Brook Milligan <brook@trillium.NMSU.Edu> writes:
> Yes, that seems to be the problem, though I don't quite recognize why
> libpgtcl works (it has the same libpgtcl refers to libpq feature, but
> I tried it quite awhile ago with pgaccess and all was fine).

On HPUX, the reason libpgtcl works as a shared lib is that it gets
installed into the same library directory as libpq.  HPUX uses a search
path for shared libs (typically embedded into the executable, though you
can arrange to look at an environment variable instead if you're so
inclined).  So, if the application was able to find libpgtcl, it'll
find libpq too.

I imagine that generally the same story holds for other systems,
but haven't looked closely.

The reason the Perl module fails is that it gets installed somewhere
else, viz. the perl library tree.  The Perl executable knows about
looking in the library tree for shlibs, but it's never heard of
/usr/local/pgsql/lib/ unless you hack it specially.

It might be that installing a copy of libpq.so into the same directory
that the perl module shlib goes into would make it work.  I haven't
tried that, but if it works it might be a better answer than this
rebuild-afterwards approach.

			regards, tom lane

Wed, 14 Oct 1998 19:25:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] perl interface bug? 
> Please let me know how it works.  I'd like to see this fixed in 6.4
> since it will remove a substantial bug in the perl interface.
> 
>    If this flies, we should rip out the commented-out cruft in
>    perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME
>    environment variable...
> 
> Absolutely.  That stuff really isn't necessary, I don't think.  I just
> didn't want to trash the file so dramatically. :)

Added to Open 6.4 items list.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 14 Oct 1998 21:49:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] perl interface bug?
Tom Lane wrote:
> 
> Brook Milligan <brook@trillium.NMSU.Edu> writes:
> > I am having problems getting the perl interface to work (but see below
> > for a fix).  If I install postgresql on a bare system (i.e., one with
> > no previous postgresql installed), the perl interface gets installed,
> > but the test.pl script fails with an undefined symbol error (libpq
> > cannot be found).  However, if I rebuild the perl interface AFTER
> > postgresql (actually, I think libpq is all that is necessary here) is
> > installed, the test.pl script works fine.
> 
> This is a longstanding problem in the Perl module.  It's fairly closely
> related to the recent flamefest about LD_LIBRARY_PATH, btw --- the
> trouble is that if shared lib A refers to shared lib B, then lib A may
> need to contain a hardwired path to lib B.  At least on some platforms.
> I think your intended fix of rebuilding the Perl shared lib after libpq
> has been installed might solve the problem nicely for these platforms.
> 
> HPUX is one of the places where there's a problem, so I'll try out your
> fix as soon as I get a chance.
> 
> If this flies, we should rip out the commented-out cruft in
> perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME
> environment variable...
> 
>                         regards, tom lane


I think the best solution is just not to build the perl interface
together with postgresql. It will never work, because 'make test' 
needs the postmaster to be up and running. 

Don't change Makefile.PL, POSTGRES_HOME is needed when building the perl
module outside the postgresql source-tree.


Edmund
-- 
Edmund Mergl          mailto:E.Mergl@bawue.de
Im Haldenhau 9        http://www.bawue.de/~mergl
70565 Stuttgart       fon: +49 711 747503
Germany

Thu, 15 Oct 1998 07:58:16 +0000
Edmund Mergl <E.Mergl@bawue.de>
Re: [HACKERS] perl interface bug?
   It might be that installing a copy of libpq.so into the same directory
   that the perl module shlib goes into would make it work.  I haven't
   tried that, but if it works it might be a better answer than this
   rebuild-afterwards approach.

NO, NO, NO!  We don't want TWO copies of libpq floating around.  The
correct solution, I think, is to make the libraries know about each
other.  My patch does that, though there may be other solutions that
do the same thing.

What we need is to determine if there are cases in which that rebuild
after install method does not work.

Cheers,
Brook

Thu, 15 Oct 1998 08:16:01 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] perl interface bug?
   I think the best solution is just not to build the perl interface
   together with postgresql. It will never work, because 'make test' 
   needs the postmaster to be up and running. 

I will argue strongly that we DO want to build the perl interface
straight out of the box.  Ideally we will have a COMPLETE system that
can be built and installed in one pass, such that every part of it
will work.  I have demonstrated that it is possible (at least on
NetBSD) to do this and still resolve the inter-library references
between the perl interface and libpq.

We cannot kill this idea because 'make test' doesn't run without the
postmaster.  After all, NONE of the regression tests do either!
Nevertheless, we still build and install the complete system; then run
the tests.  The same is applicable to the perl interface.

   Don't change Makefile.PL, POSTGRES_HOME is needed when building the perl
   module outside the postgresql source-tree.

This may be the case and is a good reason to include the conditional
in Makefile.PL.  Nothing is really lost by doing so.

Cheers,
Brook

Thu, 15 Oct 1998 08:21:13 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] perl interface bug?
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

Thu, 15 Oct 1998 11:39:27 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] perl interface bug? 
   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.

A solution:

- a default Makefile.PL that works

- a Makefile.PL replaced from Makefile.PL.in that still works with the
  above, but satisfies the second criterion.

The patches below do this and I think satisfy all considerations
(you'll let me know if they don't, right? :)

- Makefile.PL has an explanation and if POSTGRES_HOME is not set will
  print a useful message.

- Makefile.PL.in replaces that message with the right thing for
  finding the installed shared library based on configure.

- Makefile:  same as before; do the clean before installing to pick up
  the right shared library.  Note that no clean is done for any other
  targets.

- configure.in:  output Makefile.PL along with the rest.  Note also,
  that in the current version $WHOAMI is never set so the perl test
  always fails.  Perhaps this should be fixed by setting the variable
  correctly, but in any case the comments no longer agree with this
  stuff anyway.

Cheers,
Brook

===========================================================================
--- Makefile.PL.orig	Thu Oct 15 11:13:55 1998
+++ Makefile.PL	Thu Oct 15 12:16:33 1998
@@ -1,4 +1,3 @@
-# Generated automatically from Makefile.PL.in by configure.
 #-------------------------------------------------------
 #
 # $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
@@ -11,29 +10,25 @@
 use Config;
 use strict;
 
-# because the perl5 interface is always contained in the source tree,
-# we can be sure about the location of the include files and libs.
-# For development and testing we still test for POSTGRES_HOME.
-#
-#print "\nConfiguring Pg\n";
-#print "Remember to actually read the README file !\n";
-#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
-#
-#if (! $ENV{POSTGRES_HOME}) {
-#    warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
-#    foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres /home/postgres /opt/postgres)) {
-#        if (-d "$_/lib") {
-#            $ENV{POSTGRES_HOME} = $_;
-#            last;
-#        }
-#    }
-#}
-#
-#if (-d "$ENV{POSTGRES_HOME}/lib") {
-#    print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
-#} else {
-#    die "Unable to determine PostgreSQL\n";
-#}
+# This Makefile.PL is intended for standalone use when PostgreSQL is
+# already installed.  In that case, install the perl module as follows:
+# 
+#    setenv POSTGRES_HOME /path/to/root/of/installed/postgres
+#    perl Makefile.PL
+#    make
+#    make test
+#    make install
+
+# During normal installation of PostgreSQL, this file will be replaced
+# by one derived from Makefile.PL.in so that the installed shared
+# library libpq.so will be found during installation of this module.
+# As a result, the POSTGRES_HOME environment variable need not be set
+# during PostgreSQL installation.  Note that ../Makefile takes care of
+# the `perl Makefile.PL' command.  Note also that it is still possible
+# to follow the standalone installation procedure, even after
+# configuring and installing PostgreSQL, because the `else'
+# conditional branch below is identical in both Makefile.PL and
+# Makefile.PL.in.
 
 my %opts;
 
@@ -42,13 +37,16 @@
     my $cwd = `pwd`;
     chop $cwd;
 
-    %opts = (
-        NAME         => 'Pg',
-        VERSION_FROM => 'Pg.pm',
-        INC          => "-I$cwd/../libpq -I$cwd/../../include",
-        OBJECT       => "Pg\$(OBJ_EXT)",
-        LIBS         => ["-L/usr/pkg/pgsql/lib -L$cwd/../libpq -lpq"],
-    );
+    print "To install the perl interface for PostgreSQL do the following:\n";
+    print "  - install PostgreSQL\n";
+    print "  - set the POSTGRES_HOME environment variable appropriately\n";
+    print "  - in this directory ($cwd):\n";
+    print "    perl Makefile.PL\n";
+    print "    make\n";
+    print "    make test	[ with a postmaster running ]\n";
+    print "    make install\n";
+
+    exit(1);
 
 } else {
 
===========================================================================
--- interfaces/perl5/Makefile.PL.in.orig	Thu Oct 15 11:09:15 1998
+++ interfaces/perl5/Makefile.PL.in	Thu Oct 15 11:57:17 1998
@@ -0,0 +1,44 @@
+#-------------------------------------------------------
+#
+# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
+#
+# Copyright (c) 1997, 1998  Edmund Mergl
+#
+#-------------------------------------------------------
+
+use ExtUtils::MakeMaker;
+use Config;
+use strict;
+
+my %opts;
+
+if (! $ENV{POSTGRES_HOME}) {
+
+    my $cwd = `pwd`;
+    chop $cwd;
+
+    %opts = (
+        NAME         => 'Pg',
+        VERSION_FROM => 'Pg.pm',
+        INC          => "-I$cwd/../libpq -I$cwd/../../include",
+        OBJECT       => "Pg\$(OBJ_EXT)",
+        LIBS         => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
+    );
+
+} else {
+
+    %opts = (
+        NAME         => 'Pg',
+        VERSION_FROM => 'Pg.pm',
+        INC          => "-I$ENV{POSTGRES_HOME}/include",
+        OBJECT       => "Pg\$(OBJ_EXT)",
+        LIBS         => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
+    );
+}
+
+
+WriteMakefile(%opts);
+
+exit(0);
+
+# end of Makefile.PL
===========================================================================
--- interfaces/Makefile.orig	Wed Oct  7 01:00:23 1998
+++ interfaces/Makefile	Tue Oct 13 16:29:16 1998
@@ -15,13 +15,11 @@
 include $(SRCDIR)/Makefile.global
 
 
-perl-makefile-dep :=
-ifeq ($(USE_PERL), true)
-  perl-makefile-dep := perl5/Makefile
-endif
+PERL_CLEAN := DO_NOTHING
+install: PERL_CLEAN := clean
 
 
-.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
+.DEFAULT all install clean dep depend distclean:
 	$(MAKE) -C libpq $@
 	$(MAKE) -C ecpg $@
 ifeq ($(HAVE_Cplusplus), true)
@@ -33,6 +31,8 @@
 	$(MAKE) -C libpgtcl $@
 endif
 ifeq ($(USE_PERL), true)
+	-$(MAKE) -C perl5 $(PERL_CLEAN)
+	$(MAKE) perl5/Makefile
 	$(MAKE) -C perl5 $@
 endif
 ifeq ($(USE_ODBC), true)
===========================================================================
--- configure.in.orig	Thu Oct 15 01:00:20 1998
+++ configure.in	Thu Oct 15 11:54:09 1998
@@ -266,17 +266,6 @@
    [ USE_PERL=false; AC_MSG_RESULT(disabled) ]
 )
 
-#dnl Verify that postgres is already installed
-#dnl per instructions for perl interface installation
-if test "$USE_PERL" = "true"
-then
-	if test "$WHOAMI" != "root"
-	then	AC_MSG_WARN(perl support disabled; must be root to install)
-		USE_PERL=
-	fi
-fi
-export USE_PERL
-
 dnl We include odbc support unless we disable it with --with-odbc=false
 AC_MSG_CHECKING(setting USE_ODBC)
 AC_ARG_WITH(
@@ -917,6 +906,7 @@
 	interfaces/libpgtcl/Makefile
 	interfaces/odbc/GNUmakefile
 	interfaces/odbc/Makefile.global
+	interfaces/perl5/Makefile.PL
 	pl/plpgsql/src/Makefile
 	pl/plpgsql/src/mklang.sql
 	pl/tcl/mkMakefile.tcldefs.sh

Thu, 15 Oct 1998 12:28:33 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] perl interface bug?
>    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.
> 
> A solution:
> 
> - a default Makefile.PL that works
> 
> - a Makefile.PL replaced from Makefile.PL.in that still works with the
>   above, but satisfies the second criterion.
> 
> The patches below do this and I think satisfy all considerations
> (you'll let me know if they don't, right? :)
> 
> - Makefile.PL has an explanation and if POSTGRES_HOME is not set will
>   print a useful message.
> 
> - Makefile.PL.in replaces that message with the right thing for
>   finding the installed shared library based on configure.
> 
> - Makefile:  same as before; do the clean before installing to pick up
>   the right shared library.  Note that no clean is done for any other
>   targets.
> 
> - configure.in:  output Makefile.PL along with the rest.  Note also,
>   that in the current version $WHOAMI is never set so the perl test
>   always fails.  Perhaps this should be fixed by setting the variable
>   correctly, but in any case the comments no longer agree with this
>   stuff anyway.
> 
> Cheers,
> Brook

This patch does not apply properly.  Please resubmit.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 15 Oct 1998 15:26:30 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] perl interface bug?
   > 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

Thu, 15 Oct 1998 15:15:58 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] perl interface bug?
   This patch does not apply properly.  Please resubmit.

Sorry.  Here is a set that works against my copy of the BETA2
tarball.  Hope that works now.

Cheers,
Brook

===========================================================================
--- interfaces/perl5/Makefile.PL.orig	Mon Sep 28 01:00:21 1998
+++ interfaces/perl5/Makefile.PL	Thu Oct 15 12:55:19 1998
@@ -10,29 +10,25 @@
 use Config;
 use strict;
 
-# because the perl5 interface is always contained in the source tree,
-# we can be sure about the location of the include files and libs.
-# For development and testing we still test for POSTGRES_HOME.
-#
-#print "\nConfiguring Pg\n";
-#print "Remember to actually read the README file !\n";
-#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
-#
-#if (! $ENV{POSTGRES_HOME}) {
-#    warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
-#    foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres /home/postgres /opt/postgres)) {
-#        if (-d "$_/lib") {
-#            $ENV{POSTGRES_HOME} = $_;
-#            last;
-#        }
-#    }
-#}
-#
-#if (-d "$ENV{POSTGRES_HOME}/lib") {
-#    print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
-#} else {
-#    die "Unable to determine PostgreSQL\n";
-#}
+# This Makefile.PL is intended for standalone use when PostgreSQL is
+# already installed.  In that case, install the perl module as follows:
+# 
+#    setenv POSTGRES_HOME /path/to/root/of/installed/postgres
+#    perl Makefile.PL
+#    make
+#    make test
+#    make install
+
+# During normal installation of PostgreSQL, this file will be replaced
+# by one derived from Makefile.PL.in so that the installed shared
+# library libpq.so will be found during installation of this module.
+# As a result, the POSTGRES_HOME environment variable need not be set
+# during PostgreSQL installation.  Note that ../Makefile takes care of
+# the `perl Makefile.PL' command.  Note also that it is still possible
+# to follow the standalone installation procedure, even after
+# configuring and installing PostgreSQL, because the `else'
+# conditional branch below is identical in both Makefile.PL and
+# Makefile.PL.in.
 
 my %opts;
 
@@ -41,14 +37,17 @@
     my $cwd = `pwd`;
     chop $cwd;
 
-    %opts = (
-        NAME         => 'Pg',
-        VERSION_FROM => 'Pg.pm',
-        INC          => "-I$cwd/../libpq -I$cwd/../../include",
-        OBJECT       => "Pg\$(OBJ_EXT)",
-        LIBS         => ["-L$cwd/../libpq -lpq"],
-    );
+    print "To install the perl interface for PostgreSQL do the following:\n";
+    print "  - install PostgreSQL\n";
+    print "  - set the POSTGRES_HOME environment variable appropriately\n";
+    print "  - in this directory ($cwd):\n";
+    print "    perl Makefile.PL\n";
+    print "    make\n";
+    print "    make test	[ with a postmaster running ]\n";
+    print "    make install\n";
 
+    exit(1);
+  
 } else {
 
     %opts = (
===========================================================================
--- interfaces/perl5/Makefile.PL.in.orig	Thu Oct 15 11:09:15 1998
+++ interfaces/perl5/Makefile.PL.in	Thu Oct 15 11:57:17 1998
@@ -0,0 +1,44 @@
+#-------------------------------------------------------
+#
+# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
+#
+# Copyright (c) 1997, 1998  Edmund Mergl
+#
+#-------------------------------------------------------
+
+use ExtUtils::MakeMaker;
+use Config;
+use strict;
+
+my %opts;
+
+if (! $ENV{POSTGRES_HOME}) {
+
+    my $cwd = `pwd`;
+    chop $cwd;
+
+    %opts = (
+        NAME         => 'Pg',
+        VERSION_FROM => 'Pg.pm',
+        INC          => "-I$cwd/../libpq -I$cwd/../../include",
+        OBJECT       => "Pg\$(OBJ_EXT)",
+        LIBS         => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
+    );
+
+} else {
+
+    %opts = (
+        NAME         => 'Pg',
+        VERSION_FROM => 'Pg.pm',
+        INC          => "-I$ENV{POSTGRES_HOME}/include",
+        OBJECT       => "Pg\$(OBJ_EXT)",
+        LIBS         => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
+    );
+}
+
+
+WriteMakefile(%opts);
+
+exit(0);
+
+# end of Makefile.PL
===========================================================================
--- interfaces/Makefile.orig	Wed Oct  7 01:00:23 1998
+++ interfaces/Makefile	Tue Oct 13 16:29:16 1998
@@ -15,13 +15,11 @@
 include $(SRCDIR)/Makefile.global
 
 
-perl-makefile-dep :=
-ifeq ($(USE_PERL), true)
-  perl-makefile-dep := perl5/Makefile
-endif
+PERL_CLEAN := DO_NOTHING
+install: PERL_CLEAN := clean
 
 
-.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
+.DEFAULT all install clean dep depend distclean:
 	$(MAKE) -C libpq $@
 	$(MAKE) -C ecpg $@
 ifeq ($(HAVE_Cplusplus), true)
@@ -33,6 +31,8 @@
 	$(MAKE) -C libpgtcl $@
 endif
 ifeq ($(USE_PERL), true)
+	-$(MAKE) -C perl5 $(PERL_CLEAN)
+	$(MAKE) perl5/Makefile
 	$(MAKE) -C perl5 $@
 endif
 ifeq ($(USE_ODBC), true)
===========================================================================
--- configure.in.orig	Thu Oct 15 01:00:20 1998
+++ configure.in	Thu Oct 15 11:54:09 1998
@@ -266,17 +266,6 @@
    [ USE_PERL=false; AC_MSG_RESULT(disabled) ]
 )
 
-#dnl Verify that postgres is already installed
-#dnl per instructions for perl interface installation
-if test "$USE_PERL" = "true"
-then
-	if test "$WHOAMI" != "root"
-	then	AC_MSG_WARN(perl support disabled; must be root to install)
-		USE_PERL=
-	fi
-fi
-export USE_PERL
-
 dnl We include odbc support unless we disable it with --with-odbc=false
 AC_MSG_CHECKING(setting USE_ODBC)
 AC_ARG_WITH(
@@ -917,6 +906,7 @@
 	interfaces/libpgtcl/Makefile
 	interfaces/odbc/GNUmakefile
 	interfaces/odbc/Makefile.global
+	interfaces/perl5/Makefile.PL
 	pl/plpgsql/src/Makefile
 	pl/plpgsql/src/mklang.sql
 	pl/tcl/mkMakefile.tcldefs.sh

Thu, 15 Oct 1998 15:23:55 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] perl interface bug?
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

Thu, 15 Oct 1998 22:09:14 +0000
Edmund Mergl <E.Mergl@bawue.de>
Re: [HACKERS] perl interface bug?
Applied.

>    This patch does not apply properly.  Please resubmit.
> 
> Sorry.  Here is a set that works against my copy of the BETA2
> tarball.  Hope that works now.
> 
> Cheers,
> Brook
> 
> ===========================================================================
> --- interfaces/perl5/Makefile.PL.orig	Mon Sep 28 01:00:21 1998
> +++ interfaces/perl5/Makefile.PL	Thu Oct 15 12:55:19 1998
> @@ -10,29 +10,25 @@
>  use Config;
>  use strict;
>  
> -# because the perl5 interface is always contained in the source tree,
> -# we can be sure about the location of the include files and libs.
> -# For development and testing we still test for POSTGRES_HOME.
> -#
> -#print "\nConfiguring Pg\n";
> -#print "Remember to actually read the README file !\n";
> -#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
> -#
> -#if (! $ENV{POSTGRES_HOME}) {
> -#    warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
> -#    foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres /home/postgres /opt/postgres)) {
> -#        if (-d "$_/lib") {
> -#            $ENV{POSTGRES_HOME} = $_;
> -#            last;
> -#        }
> -#    }
> -#}
> -#
> -#if (-d "$ENV{POSTGRES_HOME}/lib") {
> -#    print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
> -#} else {
> -#    die "Unable to determine PostgreSQL\n";
> -#}
> +# This Makefile.PL is intended for standalone use when PostgreSQL is
> +# already installed.  In that case, install the perl module as follows:
> +# 
> +#    setenv POSTGRES_HOME /path/to/root/of/installed/postgres
> +#    perl Makefile.PL
> +#    make
> +#    make test
> +#    make install
> +
> +# During normal installation of PostgreSQL, this file will be replaced
> +# by one derived from Makefile.PL.in so that the installed shared
> +# library libpq.so will be found during installation of this module.
> +# As a result, the POSTGRES_HOME environment variable need not be set
> +# during PostgreSQL installation.  Note that ../Makefile takes care of
> +# the `perl Makefile.PL' command.  Note also that it is still possible
> +# to follow the standalone installation procedure, even after
> +# configuring and installing PostgreSQL, because the `else'
> +# conditional branch below is identical in both Makefile.PL and
> +# Makefile.PL.in.
>  
>  my %opts;
>  
> @@ -41,14 +37,17 @@
>      my $cwd = `pwd`;
>      chop $cwd;
>  
> -    %opts = (
> -        NAME         => 'Pg',
> -        VERSION_FROM => 'Pg.pm',
> -        INC          => "-I$cwd/../libpq -I$cwd/../../include",
> -        OBJECT       => "Pg\$(OBJ_EXT)",
> -        LIBS         => ["-L$cwd/../libpq -lpq"],
> -    );
> +    print "To install the perl interface for PostgreSQL do the following:\n";
> +    print "  - install PostgreSQL\n";
> +    print "  - set the POSTGRES_HOME environment variable appropriately\n";
> +    print "  - in this directory ($cwd):\n";
> +    print "    perl Makefile.PL\n";
> +    print "    make\n";
> +    print "    make test	[ with a postmaster running ]\n";
> +    print "    make install\n";
>  
> +    exit(1);
> +  
>  } else {
>  
>      %opts = (
> ===========================================================================
> --- interfaces/perl5/Makefile.PL.in.orig	Thu Oct 15 11:09:15 1998
> +++ interfaces/perl5/Makefile.PL.in	Thu Oct 15 11:57:17 1998
> @@ -0,0 +1,44 @@
> +#-------------------------------------------------------
> +#
> +# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
> +#
> +# Copyright (c) 1997, 1998  Edmund Mergl
> +#
> +#-------------------------------------------------------
> +
> +use ExtUtils::MakeMaker;
> +use Config;
> +use strict;
> +
> +my %opts;
> +
> +if (! $ENV{POSTGRES_HOME}) {
> +
> +    my $cwd = `pwd`;
> +    chop $cwd;
> +
> +    %opts = (
> +        NAME         => 'Pg',
> +        VERSION_FROM => 'Pg.pm',
> +        INC          => "-I$cwd/../libpq -I$cwd/../../include",
> +        OBJECT       => "Pg\$(OBJ_EXT)",
> +        LIBS         => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
> +    );
> +
> +} else {
> +
> +    %opts = (
> +        NAME         => 'Pg',
> +        VERSION_FROM => 'Pg.pm',
> +        INC          => "-I$ENV{POSTGRES_HOME}/include",
> +        OBJECT       => "Pg\$(OBJ_EXT)",
> +        LIBS         => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
> +    );
> +}
> +
> +
> +WriteMakefile(%opts);
> +
> +exit(0);
> +
> +# end of Makefile.PL
> ===========================================================================
> --- interfaces/Makefile.orig	Wed Oct  7 01:00:23 1998
> +++ interfaces/Makefile	Tue Oct 13 16:29:16 1998
> @@ -15,13 +15,11 @@
>  include $(SRCDIR)/Makefile.global
>  
>  
> -perl-makefile-dep :=
> -ifeq ($(USE_PERL), true)
> -  perl-makefile-dep := perl5/Makefile
> -endif
> +PERL_CLEAN := DO_NOTHING
> +install: PERL_CLEAN := clean
>  
>  
> -.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
> +.DEFAULT all install clean dep depend distclean:
>  	$(MAKE) -C libpq $@
>  	$(MAKE) -C ecpg $@
>  ifeq ($(HAVE_Cplusplus), true)
> @@ -33,6 +31,8 @@
>  	$(MAKE) -C libpgtcl $@
>  endif
>  ifeq ($(USE_PERL), true)
> +	-$(MAKE) -C perl5 $(PERL_CLEAN)
> +	$(MAKE) perl5/Makefile
>  	$(MAKE) -C perl5 $@
>  endif
>  ifeq ($(USE_ODBC), true)
> ===========================================================================
> --- configure.in.orig	Thu Oct 15 01:00:20 1998
> +++ configure.in	Thu Oct 15 11:54:09 1998
> @@ -266,17 +266,6 @@
>     [ USE_PERL=false; AC_MSG_RESULT(disabled) ]
>  )
>  
> -#dnl Verify that postgres is already installed
> -#dnl per instructions for perl interface installation
> -if test "$USE_PERL" = "true"
> -then
> -	if test "$WHOAMI" != "root"
> -	then	AC_MSG_WARN(perl support disabled; must be root to install)
> -		USE_PERL=
> -	fi
> -fi
> -export USE_PERL
> -
>  dnl We include odbc support unless we disable it with --with-odbc=false
>  AC_MSG_CHECKING(setting USE_ODBC)
>  AC_ARG_WITH(
> @@ -917,6 +906,7 @@
>  	interfaces/libpgtcl/Makefile
>  	interfaces/odbc/GNUmakefile
>  	interfaces/odbc/Makefile.global
> +	interfaces/perl5/Makefile.PL
>  	pl/plpgsql/src/Makefile
>  	pl/plpgsql/src/mklang.sql
>  	pl/tcl/mkMakefile.tcldefs.sh
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Fri, 16 Oct 1998 00:37:38 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] perl interface bug?
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

Fri, 16 Oct 1998 10:40:55 +0000
Edmund Mergl <E.Mergl@bawue.de>
Re: [HACKERS] perl interface bug?
I have thought some more about the Perl-module-install problem,
and concluded that we still don't have it quite right.  But I think
that I know how to do it right.

There are two problems remaining in Brook's latest patch:

1. Allowing Makefile.PL to be overwritten by configure from
Makefile.PL.in is a no-no.  A cardinal rule of software source
distributions is that the build procedure must not modify any of the
files that are part of the distributed fileset.  To do otherwise
creates a trap for developers (who might accidentally check in a
locally-customized copy instead of a pristine original), and a trap for
installers too (who cannot get back to the original fileset by doing
"make clean").

(I see that Bruce's actual installation of Brook's patch removed
Makefile.PL from the fileset.  That avoids the above traps, but it
breaks the original goal of keeping the perl5 subdirectory a valid
stand-alone-installable Perl module.)

2. As it stands, when building in the Postgres source tree the Perl
module's search paths for include and lib files will be /usr/local/pgsql
(or local equivalent) *first*, the source tree *second*.  This is no
good if you are installing a new Postgres version on a machine that
currently has an older one installed.  The build phase will compile
and link the Perl module against the installed version in
/usr/local/pgsql, not against the new version in the surrounding source
tree.  Sure, it'll get rebuilt correctly during the install pass, but
this approach offers no security that you actually have a working tree
until you do the install.  If it's gonna fail, you'd like to know sooner
than that...

So, what we really want is a two-phase Perl module build/install
process: during the build phase, compile and link against the files
in the surrounding tree, ignoring /usr/local/pgsql entirely.  In
the install phase (and not before then!), blow away that version and
rebuild using the already-installed include files and libpq library
file that now reside in /usr/local/pgsql.  This ensures that the
completed Perl module will have the right path to the libpq library
(if the platform demands one).

Fortunately, it's easy to do this in a way that's compatible with also
supporting stand-alone installation of the Perl module.  We make the
Perl module's Makefile.PL use relative paths (and *only* relative paths)
if POSTGRES_HOME is not defined, and we make it use POSTGRES_HOME
(*only*) if that environment variable is set.  Then we tweak the
src/interfaces Makefile so that during "make install", we do "make
clean" and then re-execute Makefile.PL *with POSTGRES_HOME set*.
So during the install phase, the Perl module is rebuilt the same way
it would be if being installed standalone.

This is actually a lot simpler than what we had before.

A free side benefit is that our regular builds will test the
standalone-install code path, so we'll know if it breaks.

I'll test and check in the necessary changes this evening, unless
I hear loud protests...

			regards, tom lane

Sat, 17 Oct 1998 20:35:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] perl interface bug? 
I envision 2 general classes of postgresql installers:  1) root, and
2) nonroot users wishing to try/use postgresql.

In the case of root sysadmins, everything (including perl) should
install out of the box.  It does so now without affecting the
standalone perl interface installation.

In the case of nonroot installers, there are two subcases: 2a) perl is
installed in system directories with only root access, and 2b) perl
was installed in some other place by the postgresql installer.

In case 2b, again there is no problem.  The install (with a suitable
--prefix=... argument to configure) should proceed unimpeded.

In case 2a, postgresql is installable under control of the
--prefix=... argument, but there will be a conflict when perl is
installed do to lack of access to the perl filesystem for the perl
interface shared library.  In this case, the installer can install
postgresql WITHOUT the --with-perl option to configure.  Later,
someone with root permission can do the 

	cd interfaces/perl5
	perl Makefile.PL
	make
	make test
	make install

sequence.  I don't see any situations that lose here.  Am I missing
something?

In conclusion, I see our current perl interface handling as addressing
all the relevant conditions (thanks to Tom Lane for finishing it
up!).

Cheers,
Brook

Mon, 19 Oct 1998 16:58:31 -0600 (MDT)
Brook Milligan <brook@trillium.NMSU.Edu>
Re: [HACKERS] perl interface bug?