|
Home > Archive > Apache Mod-Python > November 2006 > mod_python 3.3.0-dev-20061109 tests on Win32
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
mod_python 3.3.0-dev-20061109 tests on Win32
|
|
| Jeff Robbins 2006-11-13, 8:14 am |
| 3 problems found on Win32:
1) _psp didn't build and I don't know how to build it
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/test\\\\htdocs'
so the assert fails since the first string can't be found in sys.path (count
== 0)
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?
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
|
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/
> test\\\\htdocs'
>
> 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
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
|
On 12/11/2006, at 12:18 PM, Graham Dumpleton wrote:
>
> 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
| |
| Jeff Robbins 2006-11-13, 8:14 am |
| 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" <grahamd@dscpl.com.au>
To: "Jeff Robbins" <jeffr@livedata.com>
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:
>
> 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
>
| |
| Jeff Robbins 2006-11-13, 8:14 am |
| 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!
Thanks,
Jeff
----- Original Message -----
From: "Graham Dumpleton" <grahamd@dscpl.com.au>
To: "Jeff Robbins" <jeffr@livedata.com>
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:
>
>
> 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.
>
>
> 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?
>
>
> 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
>
>
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
| 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
[vbcol=seagreen]
> ----- Original Message -----
> From: "Graham Dumpleton" <grahamd@dscpl.com.au>
> To: "Jeff Robbins" <jeffr@livedata.com>
> 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
>
>
> the
> vs
> that
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
| Try follow these instructions:
http://www.modpython.org/pipermail/...ber/022092.html
If these are correct, they probably should be put in the source code if they
aren't already.
Graham
Jeff Robbins wrote ..[vbcol=seagreen]
> 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\dist>python 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" <grahamd@dscpl.com.au>
> To: "Jeff Robbins" <jeffr@livedata.com>
> 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
>
>
> the
> vs
> that
| |
| Jeff Robbins 2006-11-13, 8:14 am |
| When I run
python setup.py build
with
ext_modules = [PSPModule]
I get _psp.pyd
When I copy that into C:\Python24\Lib\site-packages\mod_python the psp tests
pass:
* Testing mod_python.psp
..
* Testing mod_python.psp parser
PASS expect{\n} got{\n}
PASS expect{\r} got{\r}
PASS expect{\t} got{\t}
PASS expect{\r\n} got{\r\n}
PASS expect{\n} got{\n}
PASS expect{'single_quotes'} got{'single_quotes'}
PASS expect{"double_quotes"} got{"double_quotes"}
..
* Testing mod_python.psp error page
In other words, the pythonic build builds _pspmodule.c and friends. I
simply don't know how to set it up to build mod_python.so. I used the
vcproj to do that.
- Jeff
----- Original Message -----
From: "Graham Dumpleton" <grahamd@dscpl.com.au>
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 ..
>
> 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
>
>
| |
| Jeff Robbins 2006-11-13, 8:14 am |
| 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" <grahamd@dscpl.com.au>
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 ..
>
> 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
>
>
| |
| Jeff Robbins 2006-11-13, 8:14 am |
| 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" <grahamd@dscpl.com.au>
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/...ber/022092.html
>
> If these are correct, they probably should be put in the source code if
> they
> aren't already.
>
> Graham
>
> Jeff Robbins wrote ..
>
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
| 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
[vbcol=seagreen]
> ----- Original Message -----
> From: "Graham Dumpleton" <grahamd@dscpl.com.au>
> 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
>
>
> if
> and
> two
| |
| Nicolas Lehuen 2006-11-13, 8:14 am |
| 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/...2092.htmlworks,
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,
Nicolas
Jeff, one important thing is that VC project files are outdated and should
not be used. The
2006/11/13, Jeff Robbins <jeffr@livedata.com>:
>
> 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" <grahamd@dscpl.com.au>
> 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
>
>
> http://www.modpython.org/pipermail/...ber/022092.html
> and
> the two
> sys.path
>
>
| |
| Nicolas Lehuen 2006-11-13, 8:14 am |
| 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 <grahamd@dscpl.com.au>:
>
> Jeff Robbins wrote ..
> and
> where
> into
>
> 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.
>
>
> In the single include directory along with ap_*.h header files etc where
> Apache
> was installed into.
>
> Graham
>
> http://www.modpython.org/pipermail/...ber/022092.html
> couldn't
> Cannot
> list
> Win32 backslash
> /
> sys.path
> DOCUMENT_ROOT),
> Win32,
>
| |
| Jeff Robbins 2006-11-13, 8:14 am |
| 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 <grahamd@dscpl.com.au>:
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
[vbcol=seagreen]
> ----- Original Message -----
> From: "Graham Dumpleton" <grahamd@dscpl.com.au>
> 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
>
>
> if
> and
> two
| |
| Jeff Robbins 2006-11-13, 8:14 am |
| 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 <grahamd@dscpl.com.au>:
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
[vbcol=seagreen]
> ----- Original Message -----
> From: "Graham Dumpleton" <grahamd@dscpl.com.au>
> 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
>
>
> if
> and
> two
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
| 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 ..[vbcol=seagreen]
> 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 <grahamd@dscpl.com.au>:
> Jeff Robbins wrote ..
> have on
> and
> the
> the
> where
> there
> into
>
> 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.
>
>
> In the single include directory along with ap_*.h header files etc
> where Apache
> was installed into.
>
> Graham
>
> code
> couldn't
> alone
> /c
> Cannot
> you
> The
> list
> in the
> backslash
> sys.path
> '/
> Win32,
> verify
| |
| Nicolas Lehuen 2006-11-13, 8:14 am |
| 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 <jeffr@livedata.com>:
>
> 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 <nicolas@lehuen.com>
> *To:* Graham Dumpleton <grahamd@dscpl.com.au>
> *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 <grahamd@dscpl.com.au>:
>
>
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
| 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
[vbcol=seagreen]
> ----- Original Message -----
> From: "Graham Dumpleton" <grahamd@dscpl.com.au>
> 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
>
>
> show
> make
> it to
> two
| |
| Graham Dumpleton 2006-11-13, 8:14 am |
| Graham Dumpleton wrote ..
> 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.
Is this crude enough.
if winbuild:
apr1 = 0
for dir in library_dirs:
if os.path.exists(os.path.join(dir, 'libapr-1.dll')):
apr1 = 1
if apr1:
libraries = ['libhttpd', 'libapr-1', 'libaprutil-1', 'ws2_32']
else:
libraries = ['libhttpd', 'libapr', 'libaprutil', 'ws2_32']
else:
libraries = ['apr-0', 'aprutil-0']
The non Windows case is wrong, but this part of the file isn't used except for Windows
that I know of. It is actually a bit strange as setup.py is still generated from setup.py.in
yet I can't see any substitutions going on by configure. Do we still need setup.py.in
anymore?
Graham
[vbcol=seagreen]
> Jeff Robbins wrote ..
> I
> I
> in
> is
> files
> source
> the
> is
> Are
> in
> the
> on
| |
| Graham Dumpleton 2006-11-14, 7:12 pm |
| Jeff, can you download:
http://svn.apache.org/viewvc/httpd/...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 ..[vbcol=seagreen]
> 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 <grahamd@dscpl.com.au>:
> Jeff Robbins wrote ..
> have on
> and
> the
> the
> where
> there
> into
>
> 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.
>
>
> In the single include directory along with ap_*.h header files etc
> where Apache
> was installed into.
>
> Graham
>
> code
> couldn't
> alone
> /c
> Cannot
> you
> The
> list
> in the
> backslash
> sys.path
> '/
> Win32,
> verify
| |
| Jeffrey Robbins 2006-11-15, 7:12 am |
| I had to change 'libapr-1.dll' to 'libapr-1.lib' to get the script to work. (the .dll files are in the bin directory on win32)
-----Original Message-----
From: "Graham Dumpleton" <grahamd@dscpl.com.au>
Date: Tuesday, Nov 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/...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
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 <grahamd@dscpl.com.au>:
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 se
| |
| Jeff Robbins 2006-11-15, 1:12 pm |
| There are a number of build warnings on Win32 that I have been looking at.
While some are no doubt windows-specific, some look to be generic C
programming errors. Is there a goal of getting to a warning-free build?
Two changes to mod_python.h remove a number of the warnings. The first
change is for Win32, and involves having the right flavor of DL_IMPORT in
play. DL_IMPORT is a deprecated pyport.h macro (from python) that lets
users of DLL functions get the correct external declaration while
implementors of these functions get the correct internal declaration.
The second change is to fix the declaration of mp_release_interpreter which
is a void, not a void *. I doubt this matters but it is an error.
APR_DECLARE_OPTIONAL_FN(void, mp_release_interpreter, ());
The remaining build warnings are attached in a txt file for anyone who
cares. I assume many are innocuous, but there are things like
python_filter() and python_input_filter() using different types for their
readbytes argument that I don't understand. Why should these two functions
declare this arg differently?
- Jeff
----- Original Message -----
From: "Graham Dumpleton" <grahamd@dscpl.com.au>
To: "Jeff Robbins" <jeffr@livedata.com>
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/...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 ..
>
| |
| Jim Gallacher 2006-11-16, 1:14 am |
| Jeff Robbins wrote:
> There are a number of build warnings on Win32 that I have been looking
> at. While some are no doubt windows-specific, some look to be generic C
> programming errors. Is there a goal of getting to a warning-free build?
I'm not sure if it's ever been said out loud, but sure, why not? That
being said, gcc doesn't complain about most of the warnings shown in
your attachment.
> Two changes to mod_python.h remove a number of the warnings.
Please avoid using C++ style comments. They have a habit of creeping
into our code because they are so darn convenient, but we are trying to
maintain our C purity. ;)
> The first
> change is for Win32, and involves having the right flavor of DL_IMPORT
> in play. DL_IMPORT is a deprecated pyport.h macro (from python) that
> lets users of DLL functions get the correct external declaration while
> implementors of these functions get the correct internal declaration.
>
> The second change is to fix the declaration of mp_release_interpreter
> which is a void, not a void *. I doubt this matters but it is an error.
> APR_DECLARE_OPTIONAL_FN(void, mp_release_interpreter, ());
>
> The remaining build warnings are attached in a txt file for anyone who
> cares. I assume many are innocuous, but there are things like
> python_filter() and python_input_filter() using different types for
> their readbytes argument that I don't understand. Why should these two
> functions declare this arg differently?
I think that may be a mistake. They should probably both use apr_off_t
rather than apr_size_t, but I wouldn't want to make that change without
tracing the path all the way through the code. There are a lot of these
sorts of issues that I think we'll need to review in conjunction with
the python2.5 / 64 bit support.
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.000001));
In these cases your compiler is complaining needlessly. None the less, I
think multiplying by 0.000001 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.000001)
where time is also apr_time_t.
Jim
| |
| Graham Dumpleton 2006-11-16, 1:14 am |
| 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.000001));
>
> In these cases your compiler is complaining needlessly. None the less,
> I
> think multiplying by 0.000001 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.000001)
> 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.
I remember also reading somewhere, which I can't now find, some discussion
about why stat structure in Python uses ints and doesn't use float when a
platform might provide for additional information. There was some good
reason for leaving it the way it was.
Graham
| |
| Jim Gallacher 2006-11-16, 1:14 am |
| Graham Dumpleton wrote:
> Jim Gallacher wrote ..
>
> 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
| |
| Graham Dumpleton 2006-11-16, 1:14 am |
| Jim Gallacher wrote ..
> Graham Dumpleton wrote:
> them as
> uses 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
| |
| Jeff Robbins 2006-11-16, 1:12 pm |
| 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" <grahamd@dscpl.com.au>
To: "Jeff Robbins" <jeffr@livedata.com>
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/...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 ..
>
|
|
|
|
|