... [Tim Peters] >> What exactly do you do to "run tests"? This is exactly what I do: >> >> svn up >> python setup.py build_ext -i >> python test.py -vv --all [Christian Theune] > I go to the build directory of the WinBuilders and run bin/test.py
1. Is there a reason to _expect_ that to work? The WinBuilders README.txt doesn't claim that it should. Would sure be nice if it did work. 2. Which Python do you use to run bin\test.py? I hope you're using bin\python.exe for that attempt anyway. 3. How did you get that far? When I change a current WinBuilders checkout to point at Zope-2.8.0-b1.tgz, doing: WinBuilders/buildout zope dies like so: """ ... Zope binaries installed successfully. Now run '"c:\Code\build\bin\python.exe" c:\Code\build\bin\mkzopeinstance.py' touch "/cygdrive/c/Code/build/lib/python/Zope/Startup/run.py" touch: cannot touch `/cygdrive/c/Code/build/lib/python/Zope/Startup/run.py': No such file or directory make: *** [/cygdrive/c/Code/build/lib/python/Zope/Startup/run.py] Error 1 """ And indeed, there is no Startup directory under lib/python/zope in SVN trunk. Which version of WinBuilders are you using? (I used current CVS HEAD) I can get beyond that by editing three lines in mk\zope.mk to refer to Zope2/Startup instead of Zope/Startup. Then the make completes. Trying "bin\python.exe bin\test.py -v" from the build directory then doesn't get anywhere, crapping out at once because (as I think you implied before) build\lib\python\ZClasses\_pmc.txt doesn't exist. > ... > Hmm. Then it might have only be the missing files. I just have a really > hard time trying to poke into that stuff and make it work. It just feels > like poking a hairy cat. It's related to this: >> Or in the case of WinBuilders, a few dozen buttons, shell scripts, >> makefiles, and tricks building on 1.6 gigabytes of Cygwin code <wink>. > Well. It's not that bad if it would work. > > - bumping a version number > - run "WinBuilders/buildout zope" > - do "build/bin/test.py" > - Upload the .exe file It is that simple for a given release, _after_ the kinks specific to that release have been worked out. But it can't stay that simple across releases because we massively rearrange code for the Windows release, trying to make a single directory under which everything on Earth lives (alll of Zope, our own Python, our own pywin32 extensions). The way that's stitched together requires sorting out all the messy interactions among a large pile of shell scripts, makefiles, and tricks, so you get sucked into all of that stuff when anything "new" happens. Like ZClasses growing important .txt, and even .fs, files, since the last release. However, I don't think this _specific_ one is WinBuilder's fault. When I look at Zope 2.8's setup.py, I see that nothing has been added here: # ZClasses setup( name='ZClasses', author=AUTHOR, packages=['ZClasses'], data_files=[['ZClasses', ['ZClasses/*.gif']], ['ZClasses/dtml', ['ZClasses/dtml/*']]], ) to record that ZClasses (or at least its tests) now requires some .txt and .fs files. That WinBuilders didn't copy those files to the build tree appears to be just a consequence of that "setup.py install" doesn't know anything about these new files (WinBuilders does an "install" to get the appropriate files copied from its src/ directory to its build/ directory). If so, that's an all-platform bug in Zope trunk's setup.py, but one that isn't visible in daily checkout testing. BTW, it's also traditional that the person building the Windows installer find and fix the new bugs in Zope's setup.py <wink>. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )