Mike Looijmans wrote:
Ok, following Jim's advice, an having read his guide, I have so far:
- Fetched the trunk version with anonymous SVN (no problem)
I've already installed apache 2.0.55 and Python 2.4.1 on this Windows
machine (the lazy way, with MSI packages).
I've also installed the latest Cygwin (all "default" packages).
However, I'm not getting anywhere in compiling mod_python. It requires
the apxs tool which is apparently not part of any Apache windows
distribution. So I grabbed the apache 2.0.55 source for windows, but
the configure script is now stuck for over half an hour on:
Configuring Apache Portable Runtime Utility library...
checking for APR-util... reconfig
configuring package in srclib/apr-util now
Nothing appears to happen.
Anyone here who can help me out getting this up and running on Windows
XP?
See my other mail - basically you do
cd dist
set APACHESRC=c:\path\to\apache (where this is the Apache2 dir in a
standard installation, now need for apache source)
build_installer
Unfortunately I haven't got the tests working yet, but this produces an
installer in dist/dist/
I wonder if it would be a good idea to have a wiki for mod_python, it
can be a nice way of collecting documentation...
David
I can also use linux machines for compile and tests (I'm not root on
any), but I do most development on this Windows system, so I need a
windows executable anyway.
PS: Haven't found any speling errors in your document...
Jim Gallacher wrote:
Mike Looijmans wrote:
Inspired by our FieldStorage work with file uploads, I also made
some implementation changes to Field and StringField in util.py. In
essense, that will make things like using form['key'] multiple times
much more efficient. Also, FieldStorage will return the same object
if called twice.
I'd like some feedback from the group on these changes, and also
some directions on what I'd need to do to get them integrated in the
mod_python beta. I have no experience whatsoever in contributing to
open source projects.
I think it's too late in the beta cycle to be rewriting code unless
it's to fix a specific, critical bug. We really, really, *really*
need to deliver 3.2 final, and I don't want to mess with working code
at this point. The changes you are suggesting are likely more
appropriate for 3.3, or possibly a 3.2 bugfix release.
As far as contributing to mod_python, well, I think you already have
the right idea: propose changes; discuss on python-dev; seek
consensus; wait for your changes to be committed by myself or
Nicolas. Bug fixes and code improvements are much more likely to be
accepted than major new features. We want mod_python to be tightly
focused on the core functionality of providing a python interface to
apache. The fancy bells and whistles are best left to frameworks that
utilize mod_python further up the application stack.
For your specific changes, I would strongly suggest that you make your
changes against the mod_python development branch, ie trunk. Also people
are much more likely to test your changes if you submit a patch rather
than offering a completely new file. This makes it easier to see what
code is being changed and avoids problems with regressions.
I've put together a "Developer's Guide" draft that I'd like to
eventually see included in either the documentation or on the
website. This document doesn't represent any offical position of the
mod_python developers, but rather just what I see as best practices
and some resources for contributors. Everyone should feel free to
offer suggestions to improve this guide. The original is in svn at:
http://svn.apache.org/repos/asf/httpd/mod_python/branches/jgallacher/docs/developers-guide.rst
And no, I have not spell checked it yet. :)