Hi Christian, first let me thank you! It is awesome how much you accomplished, and I am sure you spent quite some time working on it.
On Tue, 29 Jan 2008, Christian Stimming wrote: > I eventually managed to build the perl bindings of subversion and I > could run "git-svn" to the help output and part of the test suite. > That's the good news. Indeed, that's good news! > The "not so good" news is that I'm still not sure how to organize that > build in the ./release.sh form. Instead, I still have a long manual > recipe... whatever. Hey, I pulled back a little, because I was exhausted, and that one mail (you know which one I mean) really made me rethink my efforts. But now I think it is time to integrate (and I'll put you in as author) it into release.sh. I can do that. > Here it is: > > * I started with the temp/msys branch of msysgit (hence, I did *not* use the > work/msysfull branch) > > * I compiled libtool-1.5.22: ./configure --prefix= --build=i686-pc-mingw32 && > make && make install I'll probably just add /src/libtool/release.sh to fetch && build && install it, and then add a check for libtool >= 1.5.22 into /src/subversion/release.sh. > * I got a zlib1.dll, moved this to /bin/zlib1.dll, and created the > corresponding /lib/libz.dll.a as described in my earlier email; the existing > /lib/libz.a I removed or renamed. Maybe we should take the msys-z.dll from the recent work/new-ssh branch? > * Then I compiled subversion by hand (for whatever reason ./release.sh didn't > work yet): Unpacking both tarballs. Then > # Applying all patches, including the new one that is attached > git init > git add . > git commit -m initial > git am ../patches/0* > # Now let the build system be regenerated > ./autogen.sh > # Some more options to configure > ./configure --disable-static --enable-shared --build=i686-pc-mingw32 That should be easy. > # Here is repeatedly hung when detecting zlib, but this wasn't because of a > missing zlib - instead, it was because of a bad variable @NEON_LIBS@ or > similar in the configure file. Eventually, this disappeared after starting > from a clean tarball plus the patches and autogen.sh. I'll look into that. > make LDFLAGS="-no-undefined -Wl,-enable-auto-import -L/lib" > # This runs until some tests which can be ignored > make install > # Now we have the svn binary and DLLs already. > > make swig-pl-lib LDFLAGS="-no-undefined -Wl,-enable-auto-import -L/lib" > LIBS="-L/lib/perl5/5.8.8/msys/CORE -lperl" > make install-swig-pl-lib > # We're getting closer. > > make swig-pl CCFLAGS="-Dstrtoll=strtol" LDFLAGS="-Wl,-enable-auto-import" > # The "trick" was to learn the Makefile.PL syntax and add all the required > DLLs to be linked into. Along the way, I didn't find out *why* the Makefiles > were installed in the weird location, but through the FIRST_MAKEFILE argument > I could specify the correct one. See attached patch. > > make install-swig-pl > # That's it. Yippi-yay-yeah! > > The test output is below as well. This was all built with MSYSTEM=MSYS, > despite the --build argument of configure. And indeed all resulting DLLs will > link against "MSYS-1.0.DLL", including e.g. bin/libsvn_client-1-0.dll and the > perl modules like SVN/_Core/_Core.dll etc. Cool! > I'm short on time these days, but I might try again to integrate this > into ./release.sh, starting from a clean temp/msys tree. But unless > anyone else starts to do this, it might take me 2-3 weeks until I can > come up with something working here. If you don't mind, I'll take it further and probably come back to you with something usable by tomorrow night. You are my hero, Dscho
