Re: mod_python 3.2.3b available for testing
Nick wrote: More info: python 2.4.2 on Linux: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0xb7df07b8 type(t) type 'file' dir(t) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines', 'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines', 'xreadlines'] python 2.4.1 on windows: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0x0099FBA8 type(t) type 'instance' dir(t) ['__doc__', '__getattr__', '__init__', '__module__', '__repr__', 'close_called', 'file', 'name'] So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? I think we should correct it. I'm sure users don't care that we implement this with TemporaryFile. That being said, I wonder how many applications on Windows we may break by fixing this? Version 3.1.4 also used TemporaryFile, so this is not a new bug. Jim Nick wrote: This may be a Python Windows thing, but it shows up in mod_python: When using util.FieldStorage on multipart/form-data encoded POST data containing a file, in Linux a field.file will yield a file object (actually a subclass of file), but in Windows you have to get the file object through field.file.file. This probably has something to do with the fact that Windows' implementation of tempfile.TemporaryFile is different from Linux, but it should be made consistent in the mod_python interface. Nick
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote: So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? I think we should correct it. I'm sure users don't care that we implement this with TemporaryFile. That being said, I wonder how many applications on Windows we may break by fixing this? Version 3.1.4 also used TemporaryFile, so this is not a new bug. Yeah, I never noticed it either until someone pointed it out to me. I appreciated the change to TemporaryFile, but being primarily a Linux user I never noticed that this broke my code in Windows. In any case, I'm still gonna have to implement a workaround in my own code to catch people using the different versions of mod_python out there, so I can live with whatever decision you guys make. But here's +1 for making the interface consistent at least for mod_python users. As for code breakage, I would consider this a bug introduced in 3.1.4, which was the last official release of mod_python, which will be corrected in release 3.3. Nick
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote:
Nick wrote:
More info:
python 2.4.2 on Linux:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0xb7df07b8
type(t)
type 'file'
dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close',
'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name',
'newlines', 'next', 'read', 'readinto', 'readline', 'readlines',
'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines',
'xreadlines']
python 2.4.1 on windows:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0x0099FBA8
type(t)
type 'instance'
dir(t)
['__doc__', '__getattr__', '__init__', '__module__', '__repr__',
'close_called', 'file', 'name']
So this is an inconsistency within Python. Should mod_python attempt
to correct it, or just claim a Python bug?
I think we should correct it. I'm sure users don't care that we
implement this with TemporaryFile. That being said, I wonder how many
applications on Windows we may break by fixing this? Version 3.1.4 also
used TemporaryFile, so this is not a new bug.
Are you sure there is anything to correct? In both cases, the object has
the same methods available for manipulating files (t.write('a'), for
example). They are not the same type of object, so they have different
dir() output, but don't they have the same functionality? What
specifically gets broken in util.FieldStorage?
Re: mod_python 3.2.3b available for testing
Nick wrote: Jim Gallacher wrote: So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? I think we should correct it. I'm sure users don't care that we implement this with TemporaryFile. That being said, I wonder how many applications on Windows we may break by fixing this? Version 3.1.4 also used TemporaryFile, so this is not a new bug. Yeah, I never noticed it either until someone pointed it out to me. I appreciated the change to TemporaryFile, but being primarily a Linux user I never noticed that this broke my code in Windows. In any case, I'm still gonna have to implement a workaround in my own code to catch people using the different versions of mod_python out there, so I can live with whatever decision you guys make. But here's +1 for making the interface consistent at least for mod_python users. As for code breakage, I would consider this a bug introduced in 3.1.4, which was the last official release of mod_python, which will be corrected in release 3.3. You may have misunderstood. I was not suggesting that tempfile.TemporaryFile was introduced in 3.1.4, only that it existed there. Looking at the svn repository I see it's used in 3.0.0-beta and 2.7.9, so this bug has been lurking for a while. ;) Regards, Jim
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote: You may have misunderstood. I was not suggesting that tempfile.TemporaryFile was introduced in 3.1.4, only that it existed there. Looking at the svn repository I see it's used in 3.0.0-beta and 2.7.9, so this bug has been lurking for a while. ;) Yes, although the fact that the implementation of TemporaryFile changed in Python 2.3 may have something to do with it. I honestly don't remember what the previous behavior was, but it worked OK for me at one time :) Nick
Re: mod_python 3.2.3b available for testing
Indrek Järve wrote: This behaviour has been with Python for quite a while, so claiming it's simply a Python bug will be the same as declaring we don't support Windows. Our company's software that runs on Windows and uses mod_python simply patches util.py with the following change: 227c227 if isinstance(item.file, FileType): --- if isinstance(item.file, FileType) or (hasattr(item.file, 'file') and isinstance(item.file.file, FileType)): I haven't tried this with mp32 yet (we're still running on Python 2.3 and I haven't had time to investigate how to compile mp on Windows), but on 3.0/3.1 it appears to work just fine for our customers. The relevant part of FieldStorage has changed in 3.2. isinstance(item.file, FileType) or \ isinstance(getattr(item.file, 'file', None), FileType): so no more patching for you! Now I just need to understand what Nick is on about. ;) Jim Nick wrote: More info: python 2.4.2 on Linux: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0xb7df07b8 type(t) type 'file' dir(t) ['__class__', '__delattr__', '__doc__', '__getattribute__', '__hash__', '__init__', '__iter__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close', 'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name', 'newlines', 'next', 'read', 'readinto', 'readline', 'readlines', 'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines', 'xreadlines'] python 2.4.1 on windows: import tempfile t = tempfile.TemporaryFile() t open file 'fdopen', mode 'w+b' at 0x0099FBA8 type(t) type 'instance' dir(t) ['__doc__', '__getattr__', '__init__', '__module__', '__repr__', 'close_called', 'file', 'name'] So this is an inconsistency within Python. Should mod_python attempt to correct it, or just claim a Python bug? Nick Nick wrote: This may be a Python Windows thing, but it shows up in mod_python: When using util.FieldStorage on multipart/form-data encoded POST data containing a file, in Linux a field.file will yield a file object (actually a subclass of file), but in Windows you have to get the file object through field.file.file. This probably has something to do with the fact that Windows' implementation of tempfile.TemporaryFile is different from Linux, but it should be made consistent in the mod_python interface. Nick
Re: mod_python 3.2.3b available for testing
Jorey Bump wrote:
Jim Gallacher wrote:
Nick wrote:
More info:
python 2.4.2 on Linux:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0xb7df07b8
type(t)
type 'file'
dir(t)
['__class__', '__delattr__', '__doc__', '__getattribute__',
'__hash__', '__init__', '__iter__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__str__', 'close',
'closed', 'encoding', 'fileno', 'flush', 'isatty', 'mode', 'name',
'newlines', 'next', 'read', 'readinto', 'readline', 'readlines',
'seek', 'softspace', 'tell', 'truncate', 'write', 'writelines',
'xreadlines']
python 2.4.1 on windows:
import tempfile
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0x0099FBA8
type(t)
type 'instance'
dir(t)
['__doc__', '__getattr__', '__init__', '__module__', '__repr__',
'close_called', 'file', 'name']
So this is an inconsistency within Python. Should mod_python attempt
to correct it, or just claim a Python bug?
I think we should correct it. I'm sure users don't care that we
implement this with TemporaryFile. That being said, I wonder how many
applications on Windows we may break by fixing this? Version 3.1.4
also used TemporaryFile, so this is not a new bug.
Are you sure there is anything to correct? In both cases, the object has
the same methods available for manipulating files (t.write('a'), for
example). They are not the same type of object, so they have different
dir() output, but don't they have the same functionality? What
specifically gets broken in util.FieldStorage?
No, I'm not sure. Now that I play around with it I'm not sure I
understand the problem at all. Perhaps Nick could elaborate?
Testing with python3.2.3 on Wine:
import tempfile
from types import *
t = tempfile.TemporaryFile()
t
open file 'fdopen', mode 'w+b' at 0x40D6A560
t.file
open file 'fdopen', mode 'w+b' at 0x40D6A560
t.write('stuff')
t.seek(0)
t.read()
isinstance(t, FileType)
False
Other than the fact that isinstance(t, FileType): returns False, I
don't see the problem. Nick?
Jim
Re: mod_python 3.2.3b available for testing
-1 for Gentoo Linux 2.6.13-gentoo-r3 Apache 2.0.54 Python 2.4.1 Haven't really got time to see what it is that's causing it right now: [EMAIL PROTECTED] /usr/local/src/mod_python-3.2.3b/test $ python test.py * Testing LoadModule Creating config listen port: 32771 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing server.register_cleanup()... Creating config listen port: 32774 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing apache.register_cleanup()... Creating config listen port: 32777 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Running the per-request test suite... Creating config listen port: 32781 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf * Testing req.document_root() . * Testing req.add_handler() . * Testing req.allow_methods() . * Testing req.get_basic_auth_pw() . * Testing req.requires() . * Testing req.internal_redirect() . * Testing req.read() writing 10 bytes... response size: 10 read/write ok, now lets try causing a timeout (should be 5 secs) . * Testing req.readline() writing 120004 bytes... response size: 120004 . * Testing req.readlines() writing 120004 bytes... response size: 120004 . * Testing req.register_cleanup() . * Testing req.headers_out E * Testing req.sendfile() with offset and length . * Testing req.sendfile() without offset and length . * Testing req.sendfile() for a file which is a symbolic link . * Testing PythonOption . * Testing PythonOption override . * Testing PythonOption remove . * Testing PythonOption remove2 . * Testing util_fieldstorage() . * Testing PostReadRequestHandler . * Testing TransHandler . * Testing PythonOutputFilter . * Testing PythonConnectionHandler . * Testing PythonImport . * Testing | .ext syntax . * Testing mod_python.cgihandler . * Testing mod_python.psp . * Testing Cookie.Cookie . * Testing Cookie.MarshalCookie . * Testing Session.Session . * Testing interpreter per directive . * Testing interpreter per directory . * Testing mod_python.publisher . * Testing mod_python.publisher old-style instance publishing . * Testing mod_python.publisher instance publishing . * Testing mod_python.publisher security . * Testing mod_python.publisher iterators . * Testing mod_python.publisher hierarchy . == ERROR: test_req_headers_out (__main__.PerRequestTestCase) -- Traceback (most recent call last): File test.py, line 596, in test_req_headers_out response = conn.getresponse() File /usr/lib/python2.4/httplib.py, line 863, in getresponse response.begin() File /usr/lib/python2.4/httplib.py, line 333, in begin version, status, reason = self._read_status() File /usr/lib/python2.4/httplib.py, line 297, in _read_status raise BadStatusLine(line) BadStatusLine -- Ran 38 tests in 9.759s FAILED (errors=1) F Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf == FAIL: testPerRequestTests (__main__.PerInstanceTestCase) -- Traceback (most recent call last): File test.py, line 1488, in testPerRequestTests self.failUnless(result.wasSuccessful()) AssertionError -- Ran 4 tests in 26.496s FAILED (failures=1) Jim Gallacher wrote: A new mod_python 3.2.3 beta tarball is now available for testing. A Windows binary is also available. This release is similar to 3.2.2b but fixes a couple a small issues where a non-threaded python is used. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests
Re: mod_python 3.2.3b available for testing
Indrek Järve wrote:
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Indrek Järve wrote:
Jim Gallacher wrote:
And see if any tests fail. If they pass, send a +1 to the list, if
they
fail, send the details (the versions of OS, Python and Apache, the
test
output, and suggestions, if any).
Thank you,
Jim Gallacher
+1 on SuSE Linux 9.2 (i586)
+1 on SuSE Linux 9.2 (x86-64) once I edited the configure script and
replaced lib/ with lib64/ in PY_STD_LIB and PyLIBP
I wonder how we might correctly determine the 'lib' part of the path.
The relevant section of configure.in is:
# find out compiled in install prefix
AC_MSG_CHECKING(Python install prefix)
PyEXEC_INSTALLDIR=`$PYTHON_BIN -c import sys; print sys.exec_prefix`
AC_MSG_RESULT($PyEXEC_INSTALLDIR)
# this is where the Python libraries will get installed
AC_SUBST(PY_STD_LIB)
PY_STD_LIB=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
# set python std library variable
AC_SUBST(LIBS)
PyLIBP=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
For those of you not familiar with autoconf, we use configure.in as the
source file to generate the configure file.
Personally, I would try and use distutils to make these judgements
as to
where things live rather than constructing the standard lib directory
path
from prefix and version. For example:
python -c 'import distutils.sysconfig; print
distutils.sysconfig.get_python_lib(plat_specific=1, standard_lib=1)'
Yields:
/usr/local/sys/python/lib/python2.3
On one Solaris platform I use. On Mac OS X it yields:
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3
Indrek, can you see what this command yields for you and whether it
correctly yields what you need. Maybe it is a better of way of working
this out.
Graham
The distutils example above correctly yields /usr/lib64/python2.3/ on
the Opteron box.
OK, that looks like the way to go. I will make the correction to
configure.in and configure.
Jim
Re: mod_python 3.2.3b available for testing
+1 MacOSX 10.4.2 gcc 4.0.0 (apple) Python-2.4.2 Apache-2.0.55 cheers, Ron Ron Reisor [EMAIL PROTECTED] (RWR3) University of Delaware Information Technologies/Network and Systems Services Computing Center/192 South Chapel Street/Newark DE, 19716 pgp finger print: 0D 73 06 6F D3 6A 99 D3 F5 D5 6E FF 3B B9 7C 2C
Re: mod_python 3.2.3b available for testing
Dominic Wong wrote: -1 for Gentoo Linux 2.6.13-gentoo-r3 Apache 2.0.54 Python 2.4.1 Hi Dominic, When you have a chance could you apply the following patch and re-run the tests? Thanks, Jim Index: test/test.py === --- test/test.py(revision 327731) +++ test/test.py(working copy) @@ -590,6 +590,7 @@ print \n * Testing req.headers_out conn = httplib.HTTPConnection(127.0.0.1:%s % PORT) +conn.set_debuglevel(1) conn.putrequest(GET, /, skip_host=1) conn.putheader(Host, test_req_headers_out:%s % PORT) conn.endheaders()
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote: Dominic Wong wrote: -1 for Gentoo Linux 2.6.13-gentoo-r3 Apache 2.0.54 Python 2.4.1 Hi Dominic, When you have a chance could you apply the following patch and re-run the tests? Thanks, Jim Hi Jim, I pretty much get the same output: snip [EMAIL PROTECTED] /usr/local/src/mod_python-3.2.3b/test $ python test.py * Testing LoadModule Creating config listen port: 32863 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing server.register_cleanup()... Creating config listen port: 32866 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Testing apache.register_cleanup()... Creating config listen port: 32869 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf . * Running the per-request test suite... Creating config listen port: 32873 Starting Apache /usr/sbin/apache2 -k start -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf * Testing req.document_root() . * Testing req.add_handler() . * Testing req.allow_methods() . * Testing req.get_basic_auth_pw() . * Testing req.requires() . * Testing req.internal_redirect() . * Testing req.read() writing 10 bytes... response size: 10 read/write ok, now lets try causing a timeout (should be 5 secs) . * Testing req.readline() writing 120004 bytes... response size: 120004 . * Testing req.readlines() writing 120004 bytes... response size: 120004 . * Testing req.register_cleanup() . * Testing req.headers_out connect: (127.0.0.1, 32873) send: 'GET / HTTP/1.1\r\nAccept-Encoding: identity\r\nHost: test_req_headers_out:32873\r\n\r\n' reply: '' E * Testing req.sendfile() with offset and length . * Testing req.sendfile() without offset and length . * Testing req.sendfile() for a file which is a symbolic link . * Testing PythonOption . * Testing PythonOption override . * Testing PythonOption remove . * Testing PythonOption remove2 . * Testing util_fieldstorage() . * Testing PostReadRequestHandler . * Testing TransHandler . * Testing PythonOutputFilter . * Testing PythonConnectionHandler . * Testing PythonImport . * Testing | .ext syntax . * Testing mod_python.cgihandler . * Testing mod_python.psp . * Testing Cookie.Cookie . * Testing Cookie.MarshalCookie . * Testing Session.Session . * Testing interpreter per directive . * Testing interpreter per directory . * Testing mod_python.publisher . * Testing mod_python.publisher old-style instance publishing . * Testing mod_python.publisher instance publishing . * Testing mod_python.publisher security . * Testing mod_python.publisher iterators . * Testing mod_python.publisher hierarchy . == ERROR: test_req_headers_out (__main__.PerRequestTestCase) -- Traceback (most recent call last): File test.py, line 597, in test_req_headers_out response = conn.getresponse() File /usr/lib/python2.4/httplib.py, line 863, in getresponse response.begin() File /usr/lib/python2.4/httplib.py, line 333, in begin version, status, reason = self._read_status() File /usr/lib/python2.4/httplib.py, line 297, in _read_status raise BadStatusLine(line) BadStatusLine -- Ran 38 tests in 9.836s FAILED (errors=1) F Stopping Apache... /usr/sbin/apache2 -k stop -f /usr/local/src/mod_python-3.2.3b/test/conf/test.conf == FAIL: testPerRequestTests (__main__.PerInstanceTestCase) -- Traceback (most recent call last): File test.py, line 1489, in testPerRequestTests self.failUnless(result.wasSuccessful()) AssertionError -- Ran 4 tests in 26.450s FAILED (failures=1) /snip Cheers, Dom
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote: And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you, Jim Gallacher +1 on SuSE Linux 9.2 (i586) +1 on SuSE Linux 9.2 (x86-64) once I edited the configure script and replaced lib/ with lib64/ in PY_STD_LIB and PyLIBP Best regards, Indrek Järve Inversion Software OÜ
Re: mod_python 3.2.3b available for testing
Indrek Järve wrote:
Jim Gallacher wrote:
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you,
Jim Gallacher
+1 on SuSE Linux 9.2 (i586)
+1 on SuSE Linux 9.2 (x86-64) once I edited the configure script and
replaced lib/ with lib64/ in PY_STD_LIB and PyLIBP
I wonder how we might correctly determine the 'lib' part of the path.
The relevant section of configure.in is:
# find out compiled in install prefix
AC_MSG_CHECKING(Python install prefix)
PyEXEC_INSTALLDIR=`$PYTHON_BIN -c import sys; print sys.exec_prefix`
AC_MSG_RESULT($PyEXEC_INSTALLDIR)
# this is where the Python libraries will get installed
AC_SUBST(PY_STD_LIB)
PY_STD_LIB=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
# set python std library variable
AC_SUBST(LIBS)
PyLIBP=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
For those of you not familiar with autoconf, we use configure.in as the
source file to generate the configure file.
Regards,
Jim
Re: mod_python 3.2.3b available for testing
Jim Gallacher wrote ..
Indrek Järve wrote:
Jim Gallacher wrote:
And see if any tests fail. If they pass, send a +1 to the list, if they
fail, send the details (the versions of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you,
Jim Gallacher
+1 on SuSE Linux 9.2 (i586)
+1 on SuSE Linux 9.2 (x86-64) once I edited the configure script and
replaced lib/ with lib64/ in PY_STD_LIB and PyLIBP
I wonder how we might correctly determine the 'lib' part of the path.
The relevant section of configure.in is:
# find out compiled in install prefix
AC_MSG_CHECKING(Python install prefix)
PyEXEC_INSTALLDIR=`$PYTHON_BIN -c import sys; print sys.exec_prefix`
AC_MSG_RESULT($PyEXEC_INSTALLDIR)
# this is where the Python libraries will get installed
AC_SUBST(PY_STD_LIB)
PY_STD_LIB=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
# set python std library variable
AC_SUBST(LIBS)
PyLIBP=${PyEXEC_INSTALLDIR}/lib/python${PyVERSION}
For those of you not familiar with autoconf, we use configure.in as the
source file to generate the configure file.
Personally, I would try and use distutils to make these judgements as to
where things live rather than constructing the standard lib directory path
from prefix and version. For example:
python -c 'import distutils.sysconfig; print
distutils.sysconfig.get_python_lib(plat_specific=1, standard_lib=1)'
Yields:
/usr/local/sys/python/lib/python2.3
On one Solaris platform I use. On Mac OS X it yields:
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3
Indrek, can you see what this command yields for you and whether it
correctly yields what you need. Maybe it is a better of way of working
this out.
Graham
