Re: Python (PyGreSQL) make install patch

Peter,

On Tue, May 29, 2001 at 10:47:51PM +0200, Peter Eisentraut wrote:
> Jason Tishler writes:
> >     If this is the required (VPATH) functionality, then we can steal
> >     this from the Python build.
>
> That would be it.  Btw., the current Makefile.pre.in approach also claims
> to support VPATH, but in its own brain-dead way that makes it useless.
> It would be interesting to see whether the distutils way does better here.

Actually, the functionality is (unfortunately) in Python's setup.py and
not in Distutils itself.  So, one would have to duplicate this code
wherever needed.  Nevertheless, one can do the following when building
Python:

    $ mkdir build
    $ cd build
    $ ../configure ...
    $ make

When make invokes setup.py, special code in setup.py will prepend the
appropriate pathnames necessary for files to be found during compilation
and linking.

> >     2. Installation by a non-root user: I don't know how to solve this
> >     with Makefiles.  The only workaround I can think of is to install
> >     in a non-privileged directory and inform the user to set their
> >     PYTHONPATH appropriately.  BTW, won't non-root users have problems
> >     installing PostgreSQL in the standard directory too?
>
> The whole point here is not to install in the standard directories.
>
> More issues:
>
> 4.  DESTDIR support:  Yet to see this happen...
>
> 5.  Dependency tracking:  Haha...
>
> 6.  Respecting the choice of compiler in configure.

OK, OK, I give -- you win. :,)  Besides...

> I have attached a makefile that illustrates what I could imagine the
> replacement to be.

I like your proposed Makefile for many reasons: consistent with the
rest of the PostgreSQL make infrastructure, easy to understand, DESTDIR
support, etc.  However, PostgreSQL is now burdened with determining and
maintaining the Python shared extension cruft for all supported platforms.
I am quite willing to supply the Cygwin stuff, but you are on your own
for other platforms like AIX, etc.

See attached for patches that are necessary for Cygwin.  Note that the
first hunk of the newmakefile.patch is only necessary if you want the
ability to run the pg shared extension out of the build tree.  If so,
then it must be call _pgmodule$(DLSUFFIX).

IMO, your proposed Makefile is the way to go.  Do you (and others)
concur?  If so, will you take my Cygwin patches now or should a
(re)submit then after your stuff is committed?

BTW, if I change:

    $(INSTALL_SHLIB) $(shlib) $(DESTDIR)$(python_moduledir)/site-packages/_pgmodule$(DLSUFFIX)

to:

    $(INSTALL_SHLIB) $(shlib) $(DESTDIR)$(python_moduledir)/site-packages

then no files are installed -- only directories are created.  Is this a
known problem with config/install-sh?

> > I am certainly not a Python expert, but my impression is that
> > $(prefix)/lib/python2.1 is reserved for Python itself.  I can research
> > this one too, but I still think that the PostgreSQL modules should go
> > in $(prefix)/lib/python2.1/site-packages.
>
> Seems reasonable, but if you can find some official recommendation that
> would be great.

The only official documentation that I could find for the standard
third-party module location is from Distutils itself:

    http://www.python.org/doc/current/inst/standard-install.html#SECTION000240000000000000000

The above seems to indicate that:

    $(exec-prefix)/lib/python$(version)/site-packages

is the place for third-party modules.

Thanks,
Jason

--
Jason Tishler
Director, Software Engineering       Phone: 732.264.8770 x235
Dot Hill Systems Corp.               Fax:   732.264.8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com