Thread: Python (PyGreSQL) make install patch
The attached patch changes src/interfaces/python/GNUmakefile to use the value of DESTDIR like the rest (or at least most) of the PostgreSQL makefiles. I found this problem when trying to package a pre-built Cygwin PostgreSQL distribution, but this problem is platform independent. The problem manifests itself when one tries to install into a stagging area (e.g., to build a tarball) instead of a real install. In this case, pg.py and _pgmodule$(SO) still end up being installed in the configured prefix directory ignoring the value of DESTDIR. Unfortunately, this patch does not handle the case where PostgreSQL and Python are configured with different prefixes. Since the Python Makefile is automatically generated and does not use DESTDIR, I believe that this issue will be difficult to correct. If anyone has ideas on how to fix this issue, then I'm quite willing to rework the patch to take the suggestion into account. I tested this patch on Cygwin and Linux. 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
Looks good to me.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it withing the next 48 hours.
> The attached patch changes src/interfaces/python/GNUmakefile to use the
> value of DESTDIR like the rest (or at least most) of the PostgreSQL
> makefiles. I found this problem when trying to package a pre-built
> Cygwin PostgreSQL distribution, but this problem is platform independent.
>
> The problem manifests itself when one tries to install into a stagging
> area (e.g., to build a tarball) instead of a real install. In this case,
> pg.py and _pgmodule$(SO) still end up being installed in the configured
> prefix directory ignoring the value of DESTDIR.
>
> Unfortunately, this patch does not handle the case where PostgreSQL
> and Python are configured with different prefixes. Since the Python
> Makefile is automatically generated and does not use DESTDIR, I believe
> that this issue will be difficult to correct. If anyone has ideas on
> how to fix this issue, then I'm quite willing to rework the patch to
> take the suggestion into account.
>
> I tested this patch on Cygwin and Linux.
>
> 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, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@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
Jason Tishler writes: > Unfortunately, this patch does not handle the case where PostgreSQL > and Python are configured with different prefixes. ...which is the case more often than not. > Since the Python > Makefile is automatically generated and does not use DESTDIR, I believe > that this issue will be difficult to correct. If anyone has ideas on > how to fix this issue, then I'm quite willing to rework the patch to > take the suggestion into account. Rip out the python makefile and reimplement the build yourself. ;-) Besides DESTDIR, the python makefile doesn't support VPATH either. (It claims to do so, but it doesn't work.) I'd also like a way to install the module as non-root user. I'm quite serious about the ripping out actually, but it's probably a bit more work than you care for. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter, On Thu, May 24, 2001 at 07:48:27PM +0200, Peter Eisentraut wrote: > Rip out the python makefile and reimplement the build yourself. ;-) Did you say rip? See attached for a patch that converts from using the traditional Makefile.pre.in style of building Python extensions to the newer Distutils style. This patch is *not* final -- its more of a proof of concept to see if such a patch would be accepted when finished. > Besides DESTDIR, the python makefile doesn't support VPATH either. (It > claims to do so, but it doesn't work.) My patch will support VPATH if Distutils does. Sorry, I don't know off hand if it does, but I can find out it if you wish. > I'd also like a way to install the module as non-root user. My patch still has the above caveat. My patch also has the follow issues/changes: 1. pg.py is installed in $(prefix)/lib/python2.1/site-packages instead of $(prefix)/lib/python2.1. I believe this to be more correct or at least this what Distutils tries to do. 2. pgdb.py is also installed (as done by the original setup.py). 3. The new setup.py doesn't handle Win32 yet (like the original one sort of did). 4. The problem with different PostgreSQL and Python prefixes still exists. I believe the solution is to get the Python prefix during configure and use it in GNUmakefile instead of $(prefix). Would this patch be accepted if I resolve the above issues? And if so, which ones are requirements versus desirables? 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
Patch applied. Thanks. I know you are testing a newer one but it seemed worthwhile to get this in there. > The attached patch changes src/interfaces/python/GNUmakefile to use the > value of DESTDIR like the rest (or at least most) of the PostgreSQL > makefiles. I found this problem when trying to package a pre-built > Cygwin PostgreSQL distribution, but this problem is platform independent. > > The problem manifests itself when one tries to install into a stagging > area (e.g., to build a tarball) instead of a real install. In this case, > pg.py and _pgmodule$(SO) still end up being installed in the configured > prefix directory ignoring the value of DESTDIR. > > Unfortunately, this patch does not handle the case where PostgreSQL > and Python are configured with different prefixes. Since the Python > Makefile is automatically generated and does not use DESTDIR, I believe > that this issue will be difficult to correct. If anyone has ideas on > how to fix this issue, then I'm quite willing to rework the patch to > take the suggestion into account. > > I tested this patch on Cygwin and Linux. > > 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, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Bruce, On Fri, May 25, 2001 at 10:29:52AM -0400, Bruce Momjian wrote: > Patch applied. Thanks. You're very welcome. > I know you are testing a newer one but it > seemed worthwhile to get this in there. I was hoping that you would apply this one while the new one is being discussed. 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
> Bruce, > > On Fri, May 25, 2001 at 10:29:52AM -0400, Bruce Momjian wrote: > > Patch applied. Thanks. > > You're very welcome. > > > I know you are testing a newer one but it > > seemed worthwhile to get this in there. > > I was hoping that you would apply this one while the new one is > being discussed. Backed out. Peter E didn't like the prefix problem. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Bruce Momjian writes:
> Patch applied. Thanks. I know you are testing a newer one but it
> seemed worthwhile to get this in there.
No, no, no!
>
> > The attached patch changes src/interfaces/python/GNUmakefile to use the
> > value of DESTDIR like the rest (or at least most) of the PostgreSQL
> > makefiles. I found this problem when trying to package a pre-built
> > Cygwin PostgreSQL distribution, but this problem is platform independent.
> >
> > The problem manifests itself when one tries to install into a stagging
> > area (e.g., to build a tarball) instead of a real install. In this case,
> > pg.py and _pgmodule$(SO) still end up being installed in the configured
> > prefix directory ignoring the value of DESTDIR.
> >
> > Unfortunately, this patch does not handle the case where PostgreSQL
> > and Python are configured with different prefixes. Since the Python
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Makefile is automatically generated and does not use DESTDIR, I believe
> > that this issue will be difficult to correct. If anyone has ideas on
> > how to fix this issue, then I'm quite willing to rework the patch to
> > take the suggestion into account.
> >
> > I tested this patch on Cygwin and Linux.
> >
> > 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, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly
>
>
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
> Bruce Momjian writes: > > > Patch applied. Thanks. I know you are testing a newer one but it > > seemed worthwhile to get this in there. > > No, no, no! OK, backed out. I knew you wanted it rewritten. I forgot you didn't like it. > > > > > > The attached patch changes src/interfaces/python/GNUmakefile to use the > > > value of DESTDIR like the rest (or at least most) of the PostgreSQL > > > makefiles. I found this problem when trying to package a pre-built > > > Cygwin PostgreSQL distribution, but this problem is platform independent. > > > > > > The problem manifests itself when one tries to install into a stagging > > > area (e.g., to build a tarball) instead of a real install. In this case, > > > pg.py and _pgmodule$(SO) still end up being installed in the configured > > > prefix directory ignoring the value of DESTDIR. > > > > > > Unfortunately, this patch does not handle the case where PostgreSQL > > > and Python are configured with different prefixes. Since the Python > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > Makefile is automatically generated and does not use DESTDIR, I believe > > > that this issue will be difficult to correct. If anyone has ideas on > > > how to fix this issue, then I'm quite willing to rework the patch to > > > take the suggestion into account. > > > > > > I tested this patch on Cygwin and Linux. > > > > > > 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, skipping... ] > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 3: if posting/reading through Usenet, please send an appropriate > > > subscribe-nomail command to majordomo@postgresql.org so that your > > > message can get through to the mailing list cleanly > > > > > > -- > Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter > > -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Jason Tishler writes: > > Rip out the python makefile and reimplement the build yourself. ;-) > > Did you say rip? See attached for a patch that converts from using the > traditional Makefile.pre.in style of building Python extensions to the > newer Distutils style. This patch is *not* final -- its more of a proof > of concept to see if such a patch would be accepted when finished. I don't think this does anything in the way of fixing the outlined problems. Moreover, it won't work with Python <2.x. What I meant with "rip" was to get rid of all the makefile generating tools and write our own makefile. > My patch also has the follow issues/changes: > > 1. pg.py is installed in $(prefix)/lib/python2.1/site-packages instead of > $(prefix)/lib/python2.1. I believe this to be more correct or at least > this what Distutils tries to do. I think if you build locally from source you want site-packages and if you make a binary distribution that is considered part of the OS core then you don't. Probably go for the former by default. > 2. pgdb.py is also installed (as done by the original setup.py). Oops. > 3. The new setup.py doesn't handle Win32 yet (like the original one sort > of did). Not sure whether we are expected to care. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter,
On Fri, May 25, 2001 at 05:31:20PM +0200, Peter Eisentraut wrote:
> Jason Tishler writes:
> > > Rip out the python makefile and reimplement the build yourself. ;-)
> >
> > Did you say rip? See attached for a patch that converts from using the
> > traditional Makefile.pre.in style of building Python extensions to the
> > newer Distutils style. This patch is *not* final -- its more of a proof
> > of concept to see if such a patch would be accepted when finished.
>
> I don't think this does anything in the way of fixing the outlined
> problems.
Agreed, but I was hoping that it would set the stag to facilitate
correcting the problems with the existing version:
1. VPATH support: I was hoping that Distutils supports VPATH.
Unfortunately, my research (i.e, web searching, Python doc reading,
Distutils code grep-ing) came up empty which leads me to the
conclude that VPATH is not (currently) supported. However, the
setup.py that is part of the Python build *does* support configuring
and building in a tree that is different than the source tree.
If this is the required (VPATH) functionality, then we can steal
this from the Python build.
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?
3. Different PostgreSQL and Python prefixes: I feel that this issue
can be resolve regardless of the way this patch goes by capturing
the Python prefix during configure and using it during make install.
I'm still quite willing to do this work.
> Moreover, it won't work with Python <2.x.
The above is not quite correct -- Python 1.6 or later supports Distutils.
One can also download and install Distutils for Python 1.5.2 or earlier
from:
http://www.python.org/sigs/distutils-sig/download.html
> What I meant with "rip" was to get rid of all the makefile generating
> tools and write our own makefile.
I knew what you meant, but from my experiences enhancing Cygwin Python to
support shared extensions, I can attest that Makefile.pre.in, makesetup,
etc. is *not* a fun place to be. Can you spell M-E-T-A! :,) Sorry,
but I won't go there again. IMO, it makes much more sense to leverage
off of the Distutils effort -- especially now that the standard Python
extension modules are built this way too.
> > My patch also has the follow issues/changes:
> >
> > 1. pg.py is installed in $(prefix)/lib/python2.1/site-packages instead of
> > $(prefix)/lib/python2.1. I believe this to be more correct or at least
> > this what Distutils tries to do.
>
> I think if you build locally from source you want site-packages and if you
> make a binary distribution that is considered part of the OS core then you
> don't. Probably go for the former by default.
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.
> > 2. pgdb.py is also installed (as done by the original setup.py).
>
> Oops.
I will make sure that pgdb.py is not forgotten in the final version.
> > 3. The new setup.py doesn't handle Win32 yet (like the original one sort
> > of did).
>
> Not sure whether we are expected to care.
Good. I wasn't really willing to expend effort on Win32 and was only
going to do so if it was deemed a requirement.
So which way do I proceed? Should I continue with the Distutils version
or just fix the current scheme to handle different PostgreSQL and Python
prefixes and install pgdb.py?
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
Jason Tishler writes: > 1. VPATH support: I was hoping that Distutils supports VPATH. > Unfortunately, my research (i.e, web searching, Python doc reading, > Distutils code grep-ing) came up empty which leads me to the > conclude that VPATH is not (currently) supported. However, the > setup.py that is part of the Python build *does* support configuring > and building in a tree that is different than the source tree. > 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. > 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. > I knew what you meant, but from my experiences enhancing Cygwin Python to > support shared extensions, I can attest that Makefile.pre.in, makesetup, > etc. is *not* a fun place to be. That's why I want to rip that too. > IMO, it makes much more sense to leverage off of the Distutils effort > -- especially now that the standard Python extension modules are built > this way too. Distutils, much like MakeMaker on the Perl side, are nice for getting your Python module out to the world without spending too much time thinking about packaging. However, in the PostgreSQL tree they are part of a larger system and they are supposed to act as part of that system (by deliberate choice). And we do spend time thinking about packaging. ;-) I wouldn't mind having a setup.py available for those who want to use it. But as long as it doesn't go into the direction of fixing the outlined issues 1.-6. there is still bound to be a replacement. I have attached a makefile that illustrates what I could imagine the replacement to be. > 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. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Attachment
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
[The updated proposed new makefile for interfaces/python is attached.] [May 30th] Jason Tishler writes: > 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. AFAICT, we build shared libraries on AIX okay. > See attached for patches that are necessary for Cygwin. > @@ -13,7 +13,7 @@ include $(top_srcdir)/src/Makefile.shlib > override CFLAGS += $(CFLAGS_SL) > # (Python also has a config.h file. Be sure to use ours.) > override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) -I$(python_includedir) > -SHLIB_LINK = $(libpq) > +SHLIB_LINK = $(libpq) $(python_libspec) > > all: all-lib I'm not sure about this change. $(python_libspec) is to link an embedded python, e.g., it includes -lpython itself. I'm not sure this would work everywhere, since the module will be loaded by a python interpreter, so you could get conflicts. Does this correspond to what the current "gmake all" gives you? > $(exec-prefix)/lib/python$(version)/site-packages > > is the place for third-party modules. I have since found supporting documentation for this. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Attachment
Peter,
On Fri, Jun 22, 2001 at 08:39:28PM +0200, Peter Eisentraut wrote:
> [The updated proposed new makefile for interfaces/python is attached.]
I was just about to ping you to see if you were available to continue
working is this stuff -- thanks for getting back to me.
> > See attached for patches that are necessary for Cygwin.
>
> > @@ -13,7 +13,7 @@ include $(top_srcdir)/src/Makefile.shlib
> > override CFLAGS += $(CFLAGS_SL)
> > # (Python also has a config.h file. Be sure to use ours.)
> > override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) -I$(python_includedir)
> > -SHLIB_LINK = $(libpq)
> > +SHLIB_LINK = $(libpq) $(python_libspec)
> >
> > all: all-lib
>
> I'm not sure about this change. $(python_libspec) is to link an embedded
> python, e.g., it includes -lpython itself. I'm not sure this would work
> everywhere, since the module will be loaded by a python interpreter, so
> you could get conflicts. Does this correspond to what the current "gmake
> all" gives you?
Oops, I let a Cygwin-ism creep into the mainline source. I should have
put the change into src/makefiles/Makefile.win instead. See the first
attachment for this patch.
Also, I needed to patch your latest version of newmakefile to append
SHLIB_LINK instead of overwriting it. See the second attachment for
this patch.
To test the above, I needed to run make as follows:
$ make -f newmakefile python_includespec='-I$(python_includedir)'
grep-ing for python_includespec in the latest src/Makefile.global.in
came up empty:
$ fgrep python_includespec src/Makefile.global.in
$
Is python_includespec a new construct that is currently only in your CVS
working directory?
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
Peter, On Fri, Jun 22, 2001 at 05:28:03PM -0400, Jason Tishler wrote: > On Fri, Jun 22, 2001 at 08:39:28PM +0200, Peter Eisentraut wrote: > > [The updated proposed new makefile for interfaces/python is attached.] > > [snip] Any status regarding this iteration? 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
> Peter, > > On Fri, Jun 22, 2001 at 05:28:03PM -0400, Jason Tishler wrote: > > On Fri, Jun 22, 2001 at 08:39:28PM +0200, Peter Eisentraut wrote: > > > [The updated proposed new makefile for interfaces/python is attached.] > > > > [snip] > > Any status regarding this iteration? I am working through some backlogged emails. I should apply it today. -- Bruce Momjian | http://candle.pha.pa.us pgman@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
Jason Tishler writes: > > > [The updated proposed new makefile for interfaces/python is attached.] > Any status regarding this iteration? Done now. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter,
On Tue, Jul 10, 2001 at 06:38:31PM +0200, Peter Eisentraut wrote:
> Jason Tishler writes:
>
> > > > [The updated proposed new makefile for interfaces/python is attached.]
>
> > Any status regarding this iteration?
>
> Done now.
Thanks. I just did a cvs update, make distclean, configure ..., make
and PyGreSQL built under Cygwin without any problems.
However, I was a little surprised that you let the following Cygwin
specific code:
ifeq ($(PORTNAME), win)
override CPPFLAGS += -DUSE_DL_IMPORT
SHLIB_LINK += $(python_libspec)
endif
escape from its normal maximum security prison cell (aka Makefile.win).
Shouldn't the above stuff be denied parole and locked up again? :,)
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