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?
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. :)
--
Mike Looijmans
Philips Natlab / Topic Automation
