Python (PyGreSQL) make install patch

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

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 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

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

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

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

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

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

[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

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

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