|
David Fraser
davidf at sjsoft.com
Fri Mar 5 10:32:18 EST 2004
Gregory (Grisha) Trubetskoy wrote: >On Thu, 4 Mar 2004, David Fraser wrote: > > >>Is there a reason there hasn't been a binary made for win32 yet? >> >> >mainly because making one is a PITA... i'll get to it some time. if anyone >wants to volunteer, you are more than welcome > > Cool. We need it for our apps, so I'll do this seeing as I have got it working now... >>I'll try and look at it myself now, but using VC++ 6 so may be difficult... >>I am using Apache 2.0.48 win32 sources and Python 2.3.3 standard >>distribution... >> >> >you shouldn't need apache sources. just install the binary apache >distribution, but remember to click on the "custom" install and include >the header files. > > Thanks, that's helpful... >>Compiling Apache for windows is described here: >>http://httpd.apache.org/docs-2.0/platform/win_compiling.html >>That seems to work fine with VC++ 6 >> >> >see above; no need to compile apache > > >>Compiling mod_python for windows seems to require compiling in src based >>on the project file for VC++7 >> >> >i actually use the .net version (is that same as 7?) - sorry, it's the >only thing i have access to. > > Yes, .net is version 7. Likewise version 6 is the only one I have access to ... but shouldn't make much of a difference to people... >>I took the vc7to6_prjconverter tool from >>http://www.codeproject.com/tools/prjconverter.asp and converted the file >>for VC++6 >>Then I had to manually change paths to point to my Apache include and >>Release (lib) directories and my Python include and libs directories >> >> > > > >>(note that I didn't have to compile Python from source as the include >>and libs are included with the standard distribution...) >> >> > >correct, no need to compile your own Python either > > > >>These originally are set as $(PYTHONSRC) and $(APACHESRC) in the include >>and libs paths. >> >> > >yes. these are the only things you should set (in system preferences | >environment) > > OK, Visual C++ 6 actually can handle these settings, I just had them wrong, so there are no changes needed to the generated .dsp file... >>I also had to manually add the srclib/apr/include and >>srclib/apr-util/include directories from Apache to the include path, and >>the srclib/apr/Release and srclib/apr-util/Release directories to the >>library path. >> >> >this is because you compiled your own apache > > Right, I didn't need them when using the Apache installation + include + libs >>Then mod_python linked successfully! >> >> >cool > > >>To build the win32 installer it needs to be done in the dist directory >>(apparently under Unix) >>I had troubles trying to run configure on MinGW as it needs an apxs to >>find... >>but the APXS is not actually needed for the setup script (the code that >>used it is commented out) >>So I ran configure on Linux, and built the installer there... >>This is done by copying src/Release/mod_python.so to the dist directory. >> >> >not anymore, it now can be done under windows. In fact it *has* to because >this step also compiles _psp. > > Hmmm ... the setup.py seems to not compile _psp on windows... is there a reason for this? I will try and merge the two setup approaches by autodetecting compilability... >you DO need to manually create a setup.py from setup.py.in since >./configure, as you noted, won't work on windows > > I have now done a fresh patch (similar to another I did) which means that setup.py no longer needs configure. Basically I search through config.status and if that fails search through the sources to find MP_VERSION This can now also detect the APXS version from config.status on Unix In any case on Windows the config.status file is hard to generate ... maybe what's needed here are Windows-specific changes to enable configure to pick up the Apache path without apxs A final change I could do to setup.py.in would be to include the APXS = "@APXS@" line, then autodetect if that has not been modified by configure, and do the search in that case only... but that may be getting a bit complex This code seems to be used to find an installed mod_python.so file - but currently seems to not include it on Unix. Am I missing something? >>In fact I found that by simply copying the setup.py generated on Linux I >>could run this on Windows >>The instruction is: >> setup.py bdist_wininst --install-script=win32_postinstall.py >> >> >perhaps distutils take care of it automtically, but I've always >done it separately, building the mod_python package for the standard lib, >which would be a step just before the bdist_wininst. > > Yes, distutils should take care of this automatically... >I had to copy src and mod_python (in lib/python) to under dist (on unix >the makefiles creates symlinks, but they don't work under windows, so you >have to copy), then run > >(This has to be run from the VC++ msdos shell, since it will invoke the >compiler to build _psp.so (or _psp.dll, don't remember)) > > python setup.py build > > > I'll start trying to work the above out, just wanted to get this patch off for comments... >>I hope the above instructions are useful to anyone else trying the same >>thing. >> >> > >me too. And if someone would care to clean up the Windows build process >and make it seamless enough and contribute it as a patch, we would all >very much appreciate it. I personally dislike Windows so much, I don't >know that will ever bring myself to doing this - just building the Windows >installer is already such a horrifying experience that I usually don't >touch Windows for months thereafeter ;-) > > :-) Hopefully this is a step along the right direction, let me know >>I have not yet fully tested this binary or installer but it seemed to >>run our applications fine. >>mod_python.so and mod_python-3.1.3.win32.exe can be downloaded from: >>http://davidf.sjsoft.com/files/mod_python.so >>http://davidf.sjsoft.com/files/mod_python-3.1.3.win32.exe >> >> > >See if you can run the tests. You will have to manually rig a testconf.py >(NOTE - it will not like blanks in path names, e.g. "Program Files", the >only work around I found was using the DOS path name, which you can >determine by firing up command.exe (as opposed to cmd.exe) i believe). But >once you get past the testconf.py, usually all tests run OK. > > OK, I managed to fix the testconf.py, and will try look at autogenerating that too... An initial problem, though, was that the LockFile directive is not included in Win32 Apache, so I have attached a patch to make this depend on mod_prefork >>I would appreciate feedback (on this list) so that hopefully these can >>be included in the official release ... >> >> > >Thanks for trying! > >Grisha > > My pleasure David -------------- next part -------------- A non-text attachment was scrubbed... Name: setup-lookupall.patch Type: text/x-patch Size: 4505 bytes Desc: not available Url : http://mailman.modpython.org/pipermail/mod_python/attachments/20040305/840171d3/setup-lookupall.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: test-win32.patch Type: text/x-patch Size: 573 bytes Desc: not available Url : http://mailman.modpython.org/pipermail/mod_python/attachments/20040305/840171d3/test-win32.bin
|