Patch applied. Thanks.
---
Magnus Hagander wrote:
> > > > So, here is a new patch. Summary:
> > >
> > > There is still a hard-coded python version in "libpython23.a".
> >
> > Argh. I thought I caught them all. How the he
> > > So, here is a new patch. Summary:
> >
> > There is still a hard-coded python version in "libpython23.a".
>
> Argh. I thought I caught them all. How the heck did I miss
> such an obvious one.
> Of cuorse, it's supposed to be libpython${pytverstr}.a...
> Same for the .def file on the next l
>> The distutils module has a get_python_inc() function which
>returns the
>> include directory. If this one was used, we wouldn't have to
>hack up the
>> include path as I do now. Is there any reason this is not
>used on Unix,
>> instead of the hardcoded subdirectory-of-"python_prefix" way
>it
Magnus Hagander wrote:
The distutils module has a get_python_inc() function which returns the
include directory. If this one was used, we wouldn't have to hack up the
include path as I do now. Is there any reason this is not used on Unix,
instead of the hardcoded subdirectory-of-"python_prefix" way
>> We run the first part of the autoconf test. The one that sets
>> python_includespec. (PGAC_PATH_PYTHON) We just skip the
>parts that tries
>> to read the Makefile.
>
>It would be better to put an "if" in the PGAC_CHECK_PYTHON_EMBED_SETUP
>macro, and have it use some other technique for obtainin
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> We run the first part of the autoconf test. The one that sets
> python_includespec. (PGAC_PATH_PYTHON) We just skip the parts that tries
> to read the Makefile.
It would be better to put an "if" in the PGAC_CHECK_PYTHON_EMBED_SETUP
macro, and have it
>> No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
>> defined in config/python.m4. The line is:
>>
>> python_includespec="-I${python_prefix}/include/python${python_version
>>}"
>
>Are we reading the same code?
>
># PGAC_PATH_PYTHON
>#
># Look for Python and set t
Magnus Hagander wrote:
> No. Not that one. PGAC_PATH_PYTHON. That is a different line. It's
> defined in config/python.m4. The line is:
>
> python_includespec="-I${python_prefix}/include/python${python_version
>}"
Are we reading the same code?
# PGAC_PATH_PYTHON
#
# Look for Pyth
>> If there is a good way, that subst command could/should be changed to
>> just strip the last part of the directory. PGAC_PATH_PYTHON appends
>> te python version, which is not correct on win32.
>
>I'm curious to know how the code
>
>AC_PATH_PROG(PYTHON, python)
>
>"appends the python version".
Magnus Hagander wrote:
> If there is a good way, that subst command could/should be changed to
> just strip the last part of the directory. PGAC_PATH_PYTHON appends
> te python version, which is not correct on win32.
I'm curious to know how the code
AC_PATH_PROG(PYTHON, python)
"appends the pyth
Magnus Hagander wrote:
> This patch attempts to fix the build of plpython on win32. Needs
> autoconf of course - don't have mine working on win32, so that part
> hasn't been 100% tested. My tests involved #:ing out all the code
> that would be included by that rule, and that makes it work, so I
> t
>> This patch attempts to fix the build of plpython on win32.
>
>How is python_includespec going to get set if we don't run the
>autoconf test that finds it out? I'm quite unthrilled with hardwiring
>the python version number, as well.
We run the first part of the autoconf test. The one that sets
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This patch attempts to fix the build of plpython on win32.
How is python_includespec going to get set if we don't run the
autoconf test that finds it out? I'm quite unthrilled with hardwiring
the python version number, as well.
Hi!
This patch attempts to fix the build of plpython on win32. Needs
autoconf of course - don't have mine working on win32, so that part
hasn't been 100% tested. My tests involved #:ing out all the code that
would be included by that rule, and that makes it work, so I think we're
safe
//Magnu
14 matches
Mail list logo
