Hi Philipp! Philipp von Weitershausen wrote:
That part seems to be work in progress. I needed some time and manual changes to set up an in-place instance for a fresh sandbox.
What changes are those? A fresh Zope trunk checkout works for me. Here's what I did:
$ svn co svn+ssh://philikon@svn.zope.org/repos/main/Zope/trunk Zope-trunk $ cd Zope-trunk $ ./configure
This fails if Python 2.4.2 is installed, but this worked: $ ./configure --with-python=/usr/bin/python2.4 [I see this is meanwhile fixed :)]
$ make
works and returns this message: Zope built. Next, do 'make install' (or 'make instance' to run a Zope instance directly from the build directory). following those instructions: $ make instance printf "Zope 2.8.0-b1" >\ "/Zope-trunk/lib/python/version.txt" "/usr/bin/python2.4" "/Zope-trunk/setup.py" \ build_ext -i \ install --skip-build --home="/Zope-trunk" running build_ext running build_headers running install running install_lib warning: install_lib: 'build/lib.linux-i686-2.4' does not exist -- no Python modules to install running install_headers [...] running install_scripts error: cannot copy tree 'build/scripts-2.4': not a directory make: *** [install] Error 1 Same problems as reported by the buildbot. Renaming build/temp.linux-i686-2.4 to build/lib.linux-i686-2.4 and adding build/scripts-2.4 by hand made 'make instance' run.
That worked for me (though I usually don't do the configure; make dance, but just do an in-place build with python setup.py build -i; see also below).
Using $ python2.4 setup.py build_ext -i 'works', but doesn't create a complete instance. Did you try to start bin/zopectl? I don't even have a bin directory.
And I didn't manage to install Zope trunk to a different location. That seems to be completely screwed up.
"Not supported anymore" is the right wording here. Basically, the "configure; make; make install" dance is going to go away for an SVN checkout. A simple Makefile as we have it in Zope 3 that simply provides shortcuts for in-place builds will probably replace it.
We're not even sure if the configure dance makes sense for a release tarball. The only benefit of the ./configure script is that it (presumably) chooses the right Python for you, which isn't always what you want, anyways. At least I do ./configure --with-python=... more than half of the times. So I could just call python setup.py install with whatever Python I want in the first place.
Thanks for clarifying. Cheers, Yuppie