Re: Python (PyGreSQL) make install patch - Mailing list pgsql-patches
From | Jason Tishler |
---|---|
Subject | Re: Python (PyGreSQL) make install patch |
Date | |
Msg-id | 20010530110954.J217@dothill.com Whole thread Raw |
In response to | Re: Python (PyGreSQL) make install patch (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: Python (PyGreSQL) make install patch
|
List | pgsql-patches |
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
Attachment
pgsql-patches by date: