Re: mod_python 3.3.0-dev-20061109 tests on Win32
Graham, Here is the mod_python.vcproj file with finfoobject.c It produces a mod_python.so that is bigger than the one the command line setup.py build produces. Must be different build options. Where are the setup.py options specified? Also, this vcproj only build mod_python.so, not _psp.pyd. So it is not a replacement for the command line setup.py build. Finally, I'm pasting the build output warning from this vcproj (after applying my fixes to mod_python.h). Best regards, Jeff -- Build started: Project: mod_python, Configuration: Release Win32 -- Compiling... finfoobject.c c:\Python25\include\pyconfig.h(309) : warning C4005: 'PLATFORM' : macro redefinition c:\Program Files\Apache Software Foundation\Apache2.2\include\os.h(41) : see previous definition of 'PLATFORM' finfoobject.c(129) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_uid_t' finfoobject.c(137) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_gid_t' finfoobject.c(145) : warning C4244: 'function' : conversion from 'apr_ino_t' to 'long', possible loss of data finfoobject.c(173) : warning C4244: 'function' : conversion from 'apr_off_t' to 'long', possible loss of data finfoobject.c(183) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data finfoobject.c(191) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data finfoobject.c(199) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data util.c util.c(122) : warning C4244: 'function' : conversion from 'apr_ino_t' to 'long', possible loss of data util.c(140) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_uid_t' util.c(146) : warning C4047: 'function' : 'long' differs in levels of indirection from 'apr_gid_t' util.c(152) : warning C4244: 'function' : conversion from 'apr_off_t' to 'long', possible loss of data util.c(158) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data util.c(164) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data util.c(170) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data tableobject.c serverobject.c requestobject.c requestobject.c(886) : warning C4244: '=' : conversion from 'apr_off_t' to 'long', possible loss of data requestobject.c(986) : warning C4244: '=' : conversion from 'apr_off_t' to 'long', possible loss of data requestobject.c(1434) : warning C4244: '=' : conversion from 'apr_off_t' to 'apr_size_t', possible loss of data requestobject.c(1609) : warning C4244: 'initializing' : conversion from 'apr_off_t' to 'long', possible loss of data mod_python.c mod_python.c(429) : warning C4101: 'mutex_dir' : unreferenced local variable mod_python.c(1985) : warning C4244: 'function' : conversion from 'apr_off_t' to 'apr_size_t', possible loss of data mod_python.c(2028) : warning C4101: 'tmp_buck' : unreferenced local variable hlistobject.c hlist.c filterobject.c filterobject.c(234) : warning C4018: '' : signed/unsigned mismatch filterobject.c(243) : warning C4018: '' : signed/unsigned mismatch connobject.c connobject.c(155) : warning C4018: '' : signed/unsigned mismatch _apachemodule.c Compiling resources... Linking... Creating library .\Release/mod_python.lib and object .\Release/mod_python.exp Build log was saved at file://c:\work\mod_python-3.3.0-dev-20061109\src\Release\BuildLog.htm mod_python - 0 error(s), 25 warning(s) -- Done -- Build: 1 succeeded, 0 failed, 0 skipped - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev@httpd.apache.org Sent: Tuesday, November 14, 2006 6:03 PM Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Jeff, can you download: http://svn.apache.org/viewvc/httpd/mod_python/trunk/dist/setup.py.in?revision=475037 and use it in place of dist/setup.py.in and use build_installer.bat to confirm that it autodetects the APR lib versions okay. Also, can you send us the mod_python.vcproj file you modified to add finfoobject.c so we can include it back in mod_python source code. Thanks. Graham Jeff Robbins wrote .. Nicolas, I downloaded the stock 2.2.3 binary build. To get setup.py to link, I had to edit this: if winbuild: libraries = ['libhttpd', 'libapr-1', 'libaprutil-1', 'ws2_32'] (added the -1 to libapr and libaprutil) The resultant build produced _psp.pyd and also a mod_python_so.pyd which I renamed mod_python.so and it ran. Does this sound right? - Jeff - Original Message - From: Nicolas Lehuen To: Graham Dumpleton Cc: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 21:04 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Indeed, the APACHESRC variable has a slightly misleading name, since
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Graham Dumpleton wrote: Jim Gallacher wrote .. Several of your other warnings such as: C:\work\mod_python-3.3.0-dev-20061109\src\util.c(170) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data are the result of converting apr_time_t from microseconds to seconds: PyTuple_SET_ITEM(t, 9, PyInt_FromLong(f-ctime*0.01)); In these cases your compiler is complaining needlessly. None the less, I think multiplying by 0.01 is both sloppy and error prone for these types of conversions. I think we should do something like this: PyTuple_SET_ITEM(t, 9, PyInt_FromLong(f-ctime/ APR_USEC_PER_SEC)); or perhaps use the apr_time_sec macro: PyTuple_SET_ITEM(t, 9, PyInt_FromLong(apr_time_sec(f-ctime))); On the other hand, maybe some of these conversions could be considered bugs. Should the mtime, ctime and atime of the finfo object be restricted to 1 second resolution? For comparison, req.request_time converts to a float: PyFloat_FromDouble(time*0.01) where time is also apr_time_t. When I added struct style access in finfoobject, I deliberately left them as int's to maintain a parallel to the fact that os.stat() under Python uses ints still and that tuple access also used ints. This changed in python 2.3. From the 2.4 docs: Changed in version 2.3: If stat_float_times returns true, the time values are floats, measuring seconds. Fractions of a second may be reported if the system supports that. On Mac OS, the times are always floats. See stat_float_times for further discussion. I don't have a problem with leaving it as int however. Jim
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Jim Gallacher wrote .. Graham Dumpleton wrote: Jim Gallacher wrote .. Several of your other warnings such as: C:\work\mod_python-3.3.0-dev-20061109\src\util.c(170) : warning C4244: 'function' : conversion from 'double' to 'long', possible loss of data are the result of converting apr_time_t from microseconds to seconds: PyTuple_SET_ITEM(t, 9, PyInt_FromLong(f-ctime*0.01)); In these cases your compiler is complaining needlessly. None the less, I think multiplying by 0.01 is both sloppy and error prone for these types of conversions. I think we should do something like this: PyTuple_SET_ITEM(t, 9, PyInt_FromLong(f-ctime/ APR_USEC_PER_SEC)); or perhaps use the apr_time_sec macro: PyTuple_SET_ITEM(t, 9, PyInt_FromLong(apr_time_sec(f-ctime))); On the other hand, maybe some of these conversions could be considered bugs. Should the mtime, ctime and atime of the finfo object be restricted to 1 second resolution? For comparison, req.request_time converts to a float: PyFloat_FromDouble(time*0.01) where time is also apr_time_t. When I added struct style access in finfoobject, I deliberately left them as int's to maintain a parallel to the fact that os.stat() under Python uses ints still and that tuple access also used ints. This changed in python 2.3. From the 2.4 docs: Changed in version 2.3: If stat_float_times returns true, the time values are floats, measuring seconds. Fractions of a second may be reported if the system supports that. On Mac OS, the times are always floats. See stat_float_times for further discussion. That'll teach me for being behind the times. I still use OS supplied Python 2.3.5 on Mac OS X and thus only see integers. :-( I don't have a problem with leaving it as int however. If Python has gone forward and started using floats, I'd say it would probably be reasonable to review it at some point. Another forward looking JIRA issue for me to create later. :-) Graham
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Graham, The edit you suggested for the PythonImport test: assert(map(os.path.normpath, sys.path).count(directory) == 1 works on my Win32 build. Presumably that change would work on Linux too, yes? Wanted to let you know. Thanks, Jef - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 22:11 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:18 PM, Graham Dumpleton wrote: 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32 backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert(sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? On second thought, possibly better to use: assert(map(os.path.normpath, sys.path).count(directory) == 1) in the htdocs/tests.py file instead as it would be more robust. Graham
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Jeff Robbins wrote .. re the 'subdir' directory: I've attached a screenshot from WinZip which I used to extract the .tgz tarball. I sorted by directory so you can see that WinZip does not show the 'subdir' directory. Perhaps a flaw in WinZip? In any case, I didn't knowingly delete that directory...I only inferred it existed from reading the test code. Perhaps a stub file could be placed in 'subdir' to force WinZip to see it? I realize that this may sound like the tail wagging the dog, but I think WinZip is common on Win32 platforms. If there's another tool I should be using, I will comply! It doesn't list test/modules either which is another empty directory, although I don't know what it is for at the moment. My guess is that you might have some option enabled in WinZIP which says ignore empty directories. It would seem sensible though to stick a dummy text file in subdir to make sure it stays around if certain options to WinZIP are going to cause it to disappear. Anyway, I'll check in the normpath change and add a dummy file for good measure. Thanks. BTW, what about the _pspmodule issue you talked about? Not sure how you would be able to run the tests successfully if that module wasn't being built. Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32 backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert(sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' I don't understand the tests.py code but it looks like in the interpreter() code def interpreter(req): if req.phase == PythonFixupHandler: if req.filename[-1] != '/' and os.path.isdir(req.filename): req.write(req.interpreter) return apache.DONE return apache.OK else: req.write(req.interpreter) return apache.DONE perhaps the req.filename 'C:/work/mod_python-3.3.0-dev-20061109/ test/htdocs/subdir' is supposed to pass the os.path.isdir() test...but it doesn't. There is no 'subdir' folder under htdocs so on Win32, os.path.isdir() returns False. Maybe this is an os dependency? The 'subdir' directory exists in the tarball. Any chance you accidentally deleted it somehow? Can you in a fresh directory unpack the tarball, verify that the directory exists and then rebuild and retest? Graham
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Try follow these instructions: http://www.modpython.org/pipermail/mod_python/2006-September/022092.html If these are correct, they probably should be put in the source code if they aren't already. Graham Jeff Robbins wrote .. re: building on Win32 I tried using setup.py but even once I set APACHESRC it still couldn't find the apr* include directories. I set ext_modules = [PSPModule] alone and it built _psp.pyd no problem! C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build running build running build_py running build_ext building 'mod_python_so' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG -D_WINDOWS -IC:\work\mod_python-3.3.0-dev -20061109\src\include -IC:\work\httpd-2.2.3\include -IC:\Python24\include -IC:\P ython24\PC /TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c /FoC:\work\ mod_python-3.3.0-dev-20061109\src\mod_python.obj mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) : fatal error C1083: Cannot open inc lude file: 'apr.h': No such file or directory error: command 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.e xe' failed with exit status 2 - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32 backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert(sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' I don't understand the tests.py code but it looks like in the interpreter() code def interpreter(req): if req.phase == PythonFixupHandler: if req.filename[-1] != '/' and os.path.isdir(req.filename): req.write(req.interpreter) return apache.DONE return apache.OK else: req.write(req.interpreter) return apache.DONE perhaps the req.filename 'C:/work/mod_python-3.3.0-dev-20061109/ test/htdocs/subdir' is supposed to pass the os.path.isdir() test...but it doesn't. There is no 'subdir' folder under htdocs so on Win32, os.path.isdir() returns False. Maybe this is an os dependency? The 'subdir' directory exists in the tarball. Any chance you accidentally deleted it somehow? Can you in a fresh directory unpack the tarball, verify that the directory exists and then rebuild and retest? Graham
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Graham, I couldn't find a WinZip option that controls this. It must be a bug in its tar support, since I know it supports empty native windows directories just fine. - Jeff - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: python-dev list python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 20:12 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Jeff Robbins wrote .. re the 'subdir' directory: I've attached a screenshot from WinZip which I used to extract the .tgz tarball. I sorted by directory so you can see that WinZip does not show the 'subdir' directory. Perhaps a flaw in WinZip? In any case, I didn't knowingly delete that directory...I only inferred it existed from reading the test code. Perhaps a stub file could be placed in 'subdir' to force WinZip to see it? I realize that this may sound like the tail wagging the dog, but I think WinZip is common on Win32 platforms. If there's another tool I should be using, I will comply! It doesn't list test/modules either which is another empty directory, although I don't know what it is for at the moment. My guess is that you might have some option enabled in WinZIP which says ignore empty directories. It would seem sensible though to stick a dummy text file in subdir to make sure it stays around if certain options to WinZIP are going to cause it to disappear. Anyway, I'll check in the normpath change and add a dummy file for good measure. Thanks. BTW, what about the _pspmodule issue you talked about? Not sure how you would be able to run the tests successfully if that module wasn't being built. Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32 backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert(sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' I don't understand the tests.py code but it looks like in the interpreter() code def interpreter(req): if req.phase == PythonFixupHandler: if req.filename[-1] != '/' and os.path.isdir(req.filename): req.write(req.interpreter) return apache.DONE return apache.OK else: req.write(req.interpreter) return apache.DONE perhaps the req.filename 'C:/work/mod_python-3.3.0-dev-20061109/ test/htdocs/subdir' is supposed to pass the os.path.isdir() test...but it doesn't. There is no 'subdir' folder under htdocs so on Win32, os.path.isdir() returns False. Maybe this is an os dependency? The 'subdir' directory exists in the tarball. Any chance you accidentally deleted it somehow? Can you in a fresh directory unpack the tarball, verify that the directory exists and then rebuild and retest? Graham
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Graham, These instructions are not sufficient. The apache environment I have on windows has include files in apachesr/include but also in apachesrc/srclib/apr/include, apachesrc/srclib/apr-iconv/include, and apachesrc/srclib/apr-util/include Setting the APACHESRC environmental per the instructions only finds the includes in $APACHESRC/include but not the apr files like apr.h in the error I posted. In the vcproj file, I had to tell the IDE in some dialog where to find these include files. Is there some other environmental or is there some copy phase in the build on Linux that gets all the include files into $APACHESRC/include? Where is apr.h on your machine? Thanks, Jeff - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Try follow these instructions: http://www.modpython.org/pipermail/mod_python/2006-September/022092.html If these are correct, they probably should be put in the source code if they aren't already. Graham Jeff Robbins wrote .. re: building on Win32 I tried using setup.py but even once I set APACHESRC it still couldn't find the apr* include directories. I set ext_modules = [PSPModule] alone and it built _psp.pyd no problem! C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build running build running build_py running build_ext building 'mod_python_so' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG -D_WINDOWS -IC:\work\mod_python-3.3.0-dev -20061109\src\include -IC:\work\httpd-2.2.3\include -IC:\Python24\include -IC:\P ython24\PC /TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c /FoC:\work\ mod_python-3.3.0-dev-20061109\src\mod_python.obj mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) : fatal error C1083: Cannot open inc lude file: 'apr.h': No such file or directory error: command 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.e xe' failed with exit status 2 - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32 backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert(sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' I don't understand the tests.py code but it looks like in the interpreter() code def interpreter(req): if req.phase == PythonFixupHandler: if req.filename[-1] != '/' and os.path.isdir(req.filename): req.write(req.interpreter) return apache.DONE return apache.OK else: req.write(req.interpreter) return apache.DONE perhaps the req.filename 'C:/work/mod_python-3.3.0-dev-20061109/ test/htdocs/subdir' is supposed to pass the os.path.isdir() test...but it doesn't. There is no 'subdir' folder under htdocs so on Win32, os.path.isdir() returns False. Maybe this is an os dependency? The 'subdir' directory exists in the tarball. Any chance you accidentally deleted it somehow? Can you in a fresh directory unpack the tarball, verify that the directory exists and then rebuild and retest? Graham
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Jeff Robbins wrote .. Graham, These instructions are not sufficient. The apache environment I have on windows has include files in apachesr/include but also in apachesrc/srclib/apr/include, apachesrc/srclib/apr-iconv/include, and apachesrc/srclib/apr-util/include Setting the APACHESRC environmental per the instructions only finds the includes in $APACHESRC/include but not the apr files like apr.h in the error I posted. In the vcproj file, I had to tell the IDE in some dialog where to find these include files. Is there some other environmental or is there some copy phase in the build on Linux that gets all the include files into $APACHESRC/include? All this suggests you are setting APACHESRC to where the original source code for Apache resides. Can you see if there is a distinct area where the include files are installed into along with Apache binaries, modules, config etc. I'm not a Windows person, but do you have a \Apache2 directory with an include directory under that. If so, set APACHESRC to \Apache2. If not, then will have to hope Nicolas is reading email at the moment and comment and he is the one who normally builds the Win32 binary releases for us. Where is apr.h on your machine? In the single include directory along with ap_*.h header files etc where Apache was installed into. Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Try follow these instructions: http://www.modpython.org/pipermail/mod_python/2006-September/022092.html If these are correct, they probably should be put in the source code if they aren't already. Graham Jeff Robbins wrote .. re: building on Win32 I tried using setup.py but even once I set APACHESRC it still couldn't find the apr* include directories. I set ext_modules = [PSPModule] alone and it built _psp.pyd no problem! C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build running build running build_py running build_ext building 'mod_python_so' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG -D_WINDOWS -IC:\work\mod_python-3.3.0-dev -20061109\src\include -IC:\work\httpd-2.2.3\include -IC:\Python24\include -IC:\P ython24\PC /TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c /FoC:\work\ mod_python-3.3.0-dev-20061109\src\mod_python.obj mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) : fatal error C1083: Cannot open inc lude file: 'apr.h': No such file or directory error: command 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.e xe' failed with exit status 2 - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32 backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert(sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' I don't understand the tests.py code but it looks like in the interpreter() code def interpreter(req): if req.phase == PythonFixupHandler: if req.filename[-1] != '/' and os.path.isdir(req.filename): req.write(req.interpreter) return apache.DONE return
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Guys,First of all sorry for not intervening in the discussion earlier, I haven't had much time for mod_python development lately (hell, not much time for anything except working). The build procedure quoted by Graham at http://www.modpython.org/pipermail/mod_python/2006-September/022092.html works, but of course doesn't use the VC project files or GUI. You should not have to worry about the location of APR or anything like that, the combination of build_installer.bat and the setup.py scripts takes care of everything.Please tell us in what way this procedure fails on your computer. Again, using the VC GUI and project files is not supported right now. Regards,NicolasJeff, one important thing is that VC project files are outdated and should not be used. The 2006/11/13, Jeff Robbins [EMAIL PROTECTED]:Graham,These instructions are not sufficient.The apache environment I have on windows has include files in apachesr/include but also inapachesrc/srclib/apr/include, apachesrc/srclib/apr-iconv/include, andapachesrc/srclib/apr-util/includeSetting the APACHESRC environmental per the instructions only finds the includes in $APACHESRC/include but not the apr files like apr.h in the errorI posted.In the vcproj file, I had to tell the IDE in some dialog where tofind these include files.Is there some other environmental or is there some copy phase in the build on Linux that gets all the include files into$APACHESRC/include?Where is apr.h on your machine?Thanks,Jeff- Original Message -From: Graham Dumpleton [EMAIL PROTECTED]To: python-dev@httpd.apache.orgSent: Sunday, November 12, 2006 20:18Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Try follow these instructions:http://www.modpython.org/pipermail/mod_python/2006-September/022092.html If these are correct, they probably should be put in the source code if they aren't already. Graham Jeff Robbins wrote .. re: building on Win32 I tried using setup.py but even once I set APACHESRC it still couldn't find the apr* include directories.I set ext_modules = [PSPModule] alone and it built _psp.pyd no problem! C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build running build running build_py running build_ext building 'mod_python_so' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox/MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG -D_WINDOWS -IC:\work\mod_python-3.3.0-dev -20061109\src\include -IC:\work\httpd-2.2.3\include -IC:\Python24\include -IC:\P ython24\PC /TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c /FoC:\work\ mod_python- 3.3.0-dev-20061109\src\mod_python.obj mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) : fatal error C1083: Cannot open inc lude file: 'apr.h': No such file or directory error: command 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.e xe' failed with exit status 2 - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in thetwo paths being compared are different (no doubt due to Win32backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert( sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found insys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON- 3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' I don't understand the tests.py code but it looks like in the interpreter() code def interpreter(req): if req.phase == PythonFixupHandler: if req.filename[-1] != '/' and os.path.isdir (req.filename): req.write(req.interpreter) return apache.DONE return apache.OK else: req.write(req.interpreter) return apache.DONE perhaps the req.filename 'C:/work/mod_python-3.3.0-dev-20061109/ test/htdocs/subdir' is supposed to pass
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Indeed, the APACHESRC variable has a slightly misleading name, since it doesn't need the full blown source installation. When building mod_python I'm using a stock Win32 Apache 2.0 or 2.2 binary build downloaded from http://httpd.apache.org/, not a source distribution. It may or may not work with a source distribution, but I'm positive it does with a binary one, so Jeff, you should definitely try it this way.Regards,Nicolas 2006/11/13, Graham Dumpleton [EMAIL PROTECTED]: Jeff Robbins wrote .. Graham, These instructions are not sufficient.The apache environment I have on windows has include files in apachesr/include but also in apachesrc/srclib/apr/include, apachesrc/srclib/apr-iconv/include, and apachesrc/srclib/apr-util/include Setting the APACHESRC environmental per the instructions only finds the includes in $APACHESRC/include but not the apr files like apr.h in the error I posted.In the vcproj file, I had to tell the IDE in some dialog where to find these include files.Is there some other environmental or is there some copy phase in the build on Linux that gets all the include files into $APACHESRC/include?All this suggests you are setting APACHESRC to where the original source codefor Apache resides. Can you see if there is a distinct area where the includefiles are installed into along with Apache binaries, modules, config etc. I'm not a Windows person, but do you have a \Apache2 directory with an includedirectory under that. If so, set APACHESRC to \Apache2. If not, then will haveto hope Nicolas is reading email at the moment and comment and he is the one who normally builds the Win32 binary releases for us. Where is apr.h on your machine?In the single include directory along with ap_*.h header files etc where Apachewas installed into. Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Try follow these instructions: http://www.modpython.org/pipermail/mod_python/2006-September/022092.html If these are correct, they probably should be put in the source code if they aren't already. Graham Jeff Robbins wrote .. re: building on Win32 I tried using setup.py but even once I set APACHESRC it still couldn't find the apr* include directories.I set ext_modules = [PSPModule] alone and it built _psp.pyd no problem! C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build running build running build_py running build_ext building 'mod_python_so' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG -D_WINDOWS -IC:\work\mod_python- 3.3.0-dev -20061109\src\include -IC:\work\httpd-2.2.3\include -IC:\Python24\include -IC:\P ython24\PC /TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c /FoC:\work\ mod_python-3.3.0-dev-20061109\src\mod_python.obj mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) : fatal error C1083: Cannot open inc lude file: 'apr.h': No such file or directory error: command 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.e xe' failed with exit status 2 - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert( sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON- 3.3.0-DEV-20061109/TEST/HTDOCS/' I don't
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Nicolas,
I had a binary (with SSL support) from http://www.apachelounge.com/. That
one has no include folder so I fell back to using a source copy. Which I
built but the build doesn't consolidate the include files. I'm downloading
the apache.org win32 binary and will try again with that.
Thanks,
Jeff
- Original Message -
From:
Nicolas
Lehuen
To: Graham Dumpleton
Cc: python-dev@httpd.apache.org
Sent: Sunday, November 12, 2006
21:04
Subject: Re: mod_python
3.3.0-dev-20061109 tests on Win32
Indeed, the APACHESRC variable has a slightly misleading name,
since it doesn't need the full blown source installation. When building
mod_python I'm using a stock Win32 Apache 2.0 or 2.2 binary build downloaded
from http://httpd.apache.org/, not a
source distribution. It may or may not work with a source distribution, but
I'm positive it does with a binary one, so Jeff, you should definitely try it
this way.Regards,Nicolas
2006/11/13, Graham Dumpleton [EMAIL PROTECTED]:
Jeff
Robbins wrote .. Graham, These instructions are not
sufficient.The apache environment I have on windows has
include files in apachesr/include but also in
apachesrc/srclib/apr/include,
apachesrc/srclib/apr-iconv/include, and
apachesrc/srclib/apr-util/include Setting the
APACHESRC environmental per the instructions only finds the includes
in $APACHESRC/include but not the apr files like apr.h in the
error I posted.In the vcproj file, I had to tell the IDE
in some dialog where to find these include
files.Is there some other environmental or is there some
copy phase in the build on Linux that gets all the include files into
$APACHESRC/include?All this suggests you are setting
APACHESRC to where the original source codefor Apache resides. Can you
see if there is a distinct area where the includefiles are installed
into along with Apache binaries, modules, config etc. I'm not a Windows
person, but do you have a \Apache2 directory with an includedirectory
under that. If so, set APACHESRC to \Apache2. If not, then will haveto
hope Nicolas is reading email at the moment and comment and he is the
one who normally builds the Win32 binary releases for us.
Where is apr.h on your machine?In the single include directory along
with ap_*.h header files etc where Apachewas installed
into.Graham - Original Message - From:
"Graham Dumpleton" [EMAIL PROTECTED] To:
python-dev@httpd.apache.org Sent: Sunday, November 12, 2006
20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on
Win32 Try follow these instructions:
http://www.modpython.org/pipermail/mod_python/2006-September/022092.html
If these are correct, they probably should be put in the
source code if they aren't
already. Graham Jeff
Robbins wrote .. re: building on Win32
I tried using setup.py but even once I set
APACHESRC it still couldn't find the apr*
include directories.I set ext_modules = [PSPModule]
alone and it built _psp.pyd no
problem!
C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build
running build running build_py
running build_ext building 'mod_python_so'
extension C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\bin\cl.exe /c /nologo /Ox
/MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG
-D_WINDOWS -IC:\work\mod_python- 3.3.0-dev
-20061109\src\include -IC:\work\httpd-2.2.3\include
-IC:\Python24\include -IC:\P ython24\PC
/TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c
/FoC:\work\
mod_python-3.3.0-dev-20061109\src\mod_python.obj
mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) :
fatal error C1083: Cannot open inc
lude file: 'apr.h': No such file or directory
error: command '"C:\Program Files\Microsoft Visual Studio
.NET 2003\Vc7\bin\cl.e xe"' failed with
exit status 2 -
Original Message - From: "Graham Dumpleton" [EMAIL PROTECTED]
To: "Jeff Robbins" [EMAIL PROTECTED]
Cc: "python-dev list" python-dev@httpd.apache.org
Sent: Saturday, November 11, 2006 20:18 Subject:
Re: mod_python 3.3.0-dev-20061109 tests on Win32
On 12/11/2006, at 12:31
AM, Jeff Robbins wrote: 3
problems found on Win32:
1) _psp didn't build and I don't know how
to build it How are you trying
to build mod_python in the first place? Are you
using dist/build_installer.bat or using VisualStudio
project file. The latter
isn't really used any longer and isn't tested. We know
that it doesn't list the
finfoobject.c file for a start.
2) In the 'Testing PythonImport' test, the path separators in
the two paths being compared
Re: mod_python 3.3.0-dev-20061109 tests on Win32
That is probably reasonable as late in Apache 2.0.X releases and in Apache 2.2.X they changed from version 0.0.9 of Apache runtime library to 1.0.2 (or something like that). Thus, they are probably naming the libraries differently. Looks like we need to do some work on that script to auto detect which libraries are present and use the appropriate ones. Graham Jeff Robbins wrote .. Nicolas, I downloaded the stock 2.2.3 binary build. To get setup.py to link, I had to edit this: if winbuild: libraries = ['libhttpd', 'libapr-1', 'libaprutil-1', 'ws2_32'] (added the -1 to libapr and libaprutil) The resultant build produced _psp.pyd and also a mod_python_so.pyd which I renamed mod_python.so and it ran. Does this sound right? - Jeff - Original Message - From: Nicolas Lehuen To: Graham Dumpleton Cc: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 21:04 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Indeed, the APACHESRC variable has a slightly misleading name, since it doesn't need the full blown source installation. When building mod_python I'm using a stock Win32 Apache 2.0 or 2.2 binary build downloaded from http://httpd.apache.org/, not a source distribution. It may or may not work with a source distribution, but I'm positive it does with a binary one, so Jeff, you should definitely try it this way. Regards, Nicolas 2006/11/13, Graham Dumpleton [EMAIL PROTECTED]: Jeff Robbins wrote .. Graham, These instructions are not sufficient. The apache environment I have on windows has include files in apachesr/include but also in apachesrc/srclib/apr/include, apachesrc/srclib/apr-iconv/include, and apachesrc/srclib/apr-util/include Setting the APACHESRC environmental per the instructions only finds the includes in $APACHESRC/include but not the apr files like apr.h in the error I posted. In the vcproj file, I had to tell the IDE in some dialog where to find these include files. Is there some other environmental or is there some copy phase in the build on Linux that gets all the include files into $APACHESRC/include? All this suggests you are setting APACHESRC to where the original source code for Apache resides. Can you see if there is a distinct area where the include files are installed into along with Apache binaries, modules, config etc. I'm not a Windows person, but do you have a \Apache2 directory with an include directory under that. If so, set APACHESRC to \Apache2. If not, then will have to hope Nicolas is reading email at the moment and comment and he is the one who normally builds the Win32 binary releases for us. Where is apr.h on your machine? In the single include directory along with ap_*.h header files etc where Apache was installed into. Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Try follow these instructions: http://www.modpython.org/pipermail/mod_python/2006-September/022092.html If these are correct, they probably should be put in the source code if they aren't already. Graham Jeff Robbins wrote .. re: building on Win32 I tried using setup.py but even once I set APACHESRC it still couldn't find the apr* include directories. I set ext_modules = [PSPModule] alone and it built _psp.pyd no problem! C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build running build running build_py running build_ext building 'mod_python_so' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG -D_WINDOWS -IC:\work\mod_python- 3.3.0-dev -20061109\src\include -IC:\work\httpd-2.2.3\include -IC:\Python24\include -IC:\P ython24\PC /TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c /FoC:\work\ mod_python-3.3.0-dev-20061109\src\mod_python.obj mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) : fatal error C1083: Cannot open inc lude file: 'apr.h': No such file or directory error: command 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.e xe' failed with exit status 2 - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Yeah, the 2.2 version needs to tweak setup.py. We should include some kinf of auto-detection of the 2.2 version and act accordingly.Glad to hear that you've succeeded in building mod_python.Regards,Nicolas 2006/11/13, Jeff Robbins [EMAIL PROTECTED]: Nicolas, I downloaded the stock 2.2.3 binary build. To get setup.py to link, I had to edit this: if winbuild: libraries = ['libhttpd', 'libapr-1', 'libaprutil-1', 'ws2_32'] (added the -1 to libapr and libaprutil) The resultant build produced _psp.pyd and also a mod_python_so.pyd which I renamed mod_python.so and it ran. Does this sound right? - Jeff - Original Message - From: Nicolas Lehuen To: Graham Dumpleton Cc: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 21:04 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Indeed, the APACHESRC variable has a slightly misleading name, since it doesn't need the full blown source installation. When building mod_python I'm using a stock Win32 Apache 2.0 or 2.2 binary build downloaded from http://httpd.apache.org/, not a source distribution. It may or may not work with a source distribution, but I'm positive it does with a binary one, so Jeff, you should definitely try it this way.Regards,Nicolas 2006/11/13, Graham Dumpleton [EMAIL PROTECTED]: Jeff Robbins wrote .. Graham, These instructions are not sufficient.The apache environment I have on windows has include files in apachesr/include but also in apachesrc/srclib/apr/include, apachesrc/srclib/apr-iconv/include, and apachesrc/srclib/apr-util/include Setting the APACHESRC environmental per the instructions only finds the includes in $APACHESRC/include but not the apr files like apr.h in the error I posted.In the vcproj file, I had to tell the IDE in some dialog where to find these include files.Is there some other environmental or is there some copy phase in the build on Linux that gets all the include files into $APACHESRC/include?All this suggests you are setting APACHESRC to where the original source codefor Apache resides. Can you see if there is a distinct area where the includefiles are installed into along with Apache binaries, modules, config etc. I'm not a Windows person, but do you have a \Apache2 directory with an includedirectory under that. If so, set APACHESRC to \Apache2. If not, then will haveto hope Nicolas is reading email at the moment and comment and he is the one who normally builds the Win32 binary releases for us. Where is apr.h on your machine?In the single include directory along with ap_*.h header files etc where Apachewas installed into.Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Try follow these instructions: http://www.modpython.org/pipermail/mod_python/2006-September/022092.html If these are correct, they probably should be put in the source code if they aren't already. Graham Jeff Robbins wrote .. re: building on Win32 I tried using setup.py but even once I set APACHESRC it still couldn't find the apr* include directories.I set ext_modules = [PSPModule] alone and it built _psp.pyd no problem! C:\work\mod_python-3.3.0-dev-20061109\distpython setup.py build running build running build_py running build_ext building 'mod_python_so' extension C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /GX /DNDEBUG -DWIN32 -DNDEBUG -D_WINDOWS -IC:\work\mod_python- 3.3.0-dev -20061109\src\include -IC:\work\httpd-2.2.3\include -IC:\Python24\include -IC:\P ython24\PC /TcC:\work\mod_python-3.3.0-dev-20061109\src\mod_python.c /FoC:\work\ mod_python-3.3.0-dev-20061109\src\mod_python.obj mod_python.c c:\work\httpd-2.2.3\include\ap_config.h(25) : fatal error C1083: Cannot open inc lude file: 'apr.h': No such file or directory error: command 'C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\cl.e xe' failed with exit status 2 - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file
Re: mod_python 3.3.0-dev-20061109 tests on Win32
Jeff Robbins wrote .. Graham, I couldn't find a WinZip option that controls this. It must be a bug in its tar support, since I know it supports empty native windows directories just fine. It may well be a bug. At: http://dsd.lbl.gov/firefish/install.html it warns: Due too an obscure bug, Winzip and possibly other Windows decompression tools may miss empty directories such as tomcat/logs from tar[.gz] files. Consequently, use the .zip download file on Windows, and DO NOT decompress tar[.gz] files on Windows. There is also the comment at: http://www.cygwin.com/ml/cygwin/2000-11/msg01493.html which says: The only archiver I know which ignores empty directories is WinZip. Don't use WinZip on tar files. I'll just add the dummy file and avoid the whole issue even if a newer version of WinZIP may address the problem. Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: python-dev list python-dev@httpd.apache.org Sent: Sunday, November 12, 2006 20:12 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 Jeff Robbins wrote .. re the 'subdir' directory: I've attached a screenshot from WinZip which I used to extract the .tgz tarball. I sorted by directory so you can see that WinZip does not show the 'subdir' directory. Perhaps a flaw in WinZip? In any case, I didn't knowingly delete that directory...I only inferred it existed from reading the test code. Perhaps a stub file could be placed in 'subdir' to force WinZip to see it? I realize that this may sound like the tail wagging the dog, but I think WinZip is common on Win32 platforms. If there's another tool I should be using, I will comply! It doesn't list test/modules either which is another empty directory, although I don't know what it is for at the moment. My guess is that you might have some option enabled in WinZIP which says ignore empty directories. It would seem sensible though to stick a dummy text file in subdir to make sure it stays around if certain options to WinZIP are going to cause it to disappear. Anyway, I'll check in the normpath change and add a dummy file for good measure. Thanks. BTW, what about the _pspmodule issue you talked about? Not sure how you would be able to run the tests successfully if that module wasn't being built. Graham - Original Message - From: Graham Dumpleton [EMAIL PROTECTED] To: Jeff Robbins [EMAIL PROTECTED] Cc: python-dev list python-dev@httpd.apache.org Sent: Saturday, November 11, 2006 20:18 Subject: Re: mod_python 3.3.0-dev-20061109 tests on Win32 On 12/11/2006, at 12:31 AM, Jeff Robbins wrote: 3 problems found on Win32: 1) _psp didn't build and I don't know how to build it How are you trying to build mod_python in the first place? Are you using dist/build_installer.bat or using VisualStudio project file. The latter isn't really used any longer and isn't tested. We know that it doesn't list the finfoobject.c file for a start. 2) In the 'Testing PythonImport' test, the path separators in the two paths being compared are different (no doubt due to Win32 backslash vs forward slash issues) the tests.py code does this: directory = os.path.dirname(__file__) assert(sys.path.count(directory) == 1) os.path.dirname(__file__) is 'C:\\work\\mod_python-3.3.0- dev-20061109\\test\\htdocs' yet sys.path has this in it 'C:/work/mod_python-3.3.0-dev-20061109/ testhtdocs' so the assert fails since the first string can't be found in sys.path (count == 0) If in test/test.py you change: c = Container(PythonPath([r'%s']+sys.path % DOCUMENT_ROOT), to: c = Container(PythonPath([r'%s']+sys.path % os.path.normpath(DOCUMENT_ROOT)), does it pass? 3) in test_interpreter_per_directory() the code does this: rsp = self.vhost_get(test_interpreter_per_directory, '/ subdir/foo.py').upper() interpreter+'SUBDIR/' is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/ TEST/HTDOCS/SUBDIR/' rsp is 'C:/WORK/MOD_PYTHON-3.3.0-DEV-20061109/TEST/HTDOCS/' I don't understand the tests.py code but it looks like in the interpreter() code def interpreter(req): if req.phase == PythonFixupHandler: if req.filename[-1] != '/' and os.path.isdir(req.filename): req.write(req.interpreter) return apache.DONE return apache.OK else: req.write(req.interpreter) return apache.DONE perhaps the req.filename 'C:/work/mod_python-3.3.0-dev-20061109/ test/htdocs/subdir' is supposed to pass the os.path.isdir() test...but it doesn't. There is no 'subdir' folder under htdocs so on Win32, os.path.isdir() returns False. Maybe this is an os dependency? The 'subdir' directory exists in the tarball. Any chance
