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