So, we've frozen the 1.3.x branch, all ready for release of the RC1.
The magic revision number is r16899. Time for drinks and testing.
Really? Well, no, not quite. As Ben Reser wasn't answering, I
started deploying my own tarball cutting factory, with the help of the
folks on #svn-dev. And, when the critical moment of running dist.sh
came, we had a rather unpleasant surprise:
Generating SWIG code...
swig [... lotsa parameters...]
subversion/bindings/swig/include/apr.swg:59: Error: Unable to find 'apr.h'
make: *** [subversion/bindings/swig/python/core.c] Error 1
As you may know, this release of Subversion is supposed to be the
first which features easy to build bindings: only the release manager
runs Swig, Swig produces massive C files with no dependancy on Swig,
and the users can just compile those to build the bindings.
However, as far as we were able to understand on the channel, Swig
tries to build binding sources that depend on apr.h. The thing is, we
can't depend on apr.h at tarball cutting time, because the actual
contents of apr.h is system dependant.
This is why swig is not finding apr.h: it doesn't exist in the
unconfigured apr sources. The problem is the same with any library
controlled by autoconf: the files are generated at configure time to
match the target system.
So, the bottom line of this, as far as we can tell, is that we cannot
build the swig bindings at tarball cutting time. Which means we go on
doing what we did in previous releases: distributing the unprocessed
swig bindings, and having users build it completely on their system.
Have we missed something vital about how the Swig bindings work, or
are we right? In the latter case, we need a patch so that the scripts
don't try to build the swig bindings at autogen time, and return to
building them at make time, as before.
Please advise, Swig & build system gurus, so that we can roll the rc.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 22 00:55:20 2005