On 19.10.2019 11:45, Yasuhito FUTATSUKI wrote: > On 2019/10/18 8:39, Branko Čibej wrote: >> On 17.10.2019 23:46, Branko Čibej wrote: >>> On 17.10.2019 23:01, Daniel Shahaf wrote: >>>> Branko Čibej wrote on Thu, Oct 17, 2019 at 22:56:29 +0200: >>>>> On 17.10.2019 22:37, Daniel Shahaf wrote: >>>>>> Branko Čibej wrote on Thu, 17 Oct 2019 06:49 +00:00: >>>>>>> On 16.10.2019 10:01, Daniel Shahaf wrote: >>>>>>>> Which reminds me: it'd be nice to set up a buildbot to run the >>>>>>>> build and >>>>>>>> test process under Python 3. Any committer can edit the buildbot >>>>>>>> scripts[1], but the question is which of the buildbot slaves >>>>>>>> has Python 3 >>>>>>>> installed? >>>>>>> https://ci.apache.org/builders/svn-x64-macosx-local-python3 >>>>>>> >>>>>>> Been there, done that, bought the DVD. >>>>>> Why are svnadmin_tests 69 and tree_conflict_tests 26 passing on that >>>>>> bot? They (currently) fail under python3. >>>>> I don't know. It's possible, I suppose, that the activation of the >>>>> python3 virtual environment has no effect on the test driver. It >>>>> might >>>>> not be a bad idea to have the tests print the Python version in the >>>>> summary and possibly in the log of every test case. >>>> What's the value of $(PYTHON) in Makefile? That's what the «check» >>>> target uses. >>> >>> Yep, apparently that's the bug ... I'm testing script changes now, >>> along >>> with r1868566 for good measure. >> >> I've set up this: >> https://ci.apache.org/builders/svn-x64-macosx-local-python3-swig >> >> It will build and test the core libraries and swig-py bindings with >> Python 3 on the swig-py3 branch. >> >> I hope ... build #0 running as we speak. > > Unfortunately build #2, which ran after upgrading SWIG and Python, failed > to build SWIG Python bindings because of SWIG 4.0, as reported on > SVN-4818. > > This also affects on trunk with SWIG 4.0. > (e.g. https://ci.apache.org/builders/svn-x64-macosx-full/builds/2418) > > With attached patch on trunk (trunk_build_with_swig4_patch.txt) and > on swig-py3 (swig_py3_build_with_swig4_patch.txt), *.so can be produced, > but the modules don't work correctly. > > It seems they were caused by incompatibility of Python code for proxy > object generated by SWIG, and it can not be resolved so simple.... > (importlib module vs simply use 'import', absense of _swig_setattr() > and _swig_getattr(), etc.)
My bad. I downgraded to Swig 3.0.12 and restarted the failed builds. -- Brane
