Just to bring a bit of closure here, so far my testing with the Python 3 bindings has been really encouraging. Once I wrapped my brain around the whole string/bytestring thing, upgrading existing consumers of the bindings has thus far been relatively straightforward.
As for the Docker-based release process stuff I attached in my previous message, I've since thrown that onto Github so anyone else who cares can benefit from/improve it. See https://github.com/cmpilato/subversion-dist . Thanks again for the tarball assembly help! -- Mike -- Mike ________________________________ From: Michael Pilato <cmpil...@collab.net> Sent: Friday, March 13, 2020 3:03 PM To: Yasuhito FUTATSUKI <futat...@poem.co.jp>; dev@subversion.apache.org <dev@subversion.apache.org> Subject: Re: A little pre-packaging help, please? [EXTERNAL EMAIL] I'm attaching what I used to make this work, which is a Docker-based process. Just expand the tarball, enter the resulting directory, and run ./docker-build.sh. ________________________________ From: Michael Pilato <cmpil...@collab.net> Sent: Friday, March 13, 2020 2:49 PM To: Yasuhito FUTATSUKI <futat...@poem.co.jp>; dev@subversion.apache.org <dev@subversion.apache.org> Subject: Re: A little pre-packaging help, please? [EXTERNAL EMAIL] > However as I wrote before[1] it is need to specify SWIG_PY_OPTS > shell/environment variable to generate SWIG Python bindings C source > and support codes. The value of SWIG_PY_OPTS depends on which is its > target py2 or py3, on which SWIG version is prior 4.0 or not. This was the key thing lacking! When I added the SWIG_PY_OPTS stuff you recommended to the release.py command-line, those files generated as expected. (And I wound up with what appears to be working build, including Python3 bindings.)
