On 2019/10/29 2:45, Branko Čibej wrote:
> On Mon 28 Oct 2019, 15:11 Yasuhito FUTATSUKI, <futatuki_at_poem.co.jp> wrote:
>
>> (I sent this message 40 hours ago, however it is not derivered yet,
>> so I send again ....)
>>
>> On 2019/10/23 6:36, Yasuhito FUTATSUKI wrote:
>>> I ran check-swig-{py|pl|rb} with some SWIG versions on swig-py3 branch.
>>>
>>> Environment:
>>> OS: FreeBSD 11.2
>>> Python 2: 2.7.16
>>> Python 3: 3.7.3
>>> Perl: 5.28.2
>>> Ruby: 2.5.5p157
>>>
>>> Results are below.
>>
>> <snip>
>>
>>> SWIG 3.0.9:
>>> Python 2 ... can't import modules
>>> (regression, fixed in SWIG 3.0.10)[2]
>>> Python 3 ... can't import modules
>>> (regression, fixed in SWIG 3.0.10)[2]
>>> Perl ... PASS
>>> Ruby ... 100% passed
>>
>>
>> With patch against Makefile.in below, which makes install time module
>> hierarchy in build/test directory by using symbolic link in
>> copy-swig-py target, 'make check-swig-py' passed with SWIG 3.0.9,
>> both with Python 2 and with Python 3.
>>
>> [[[
>> Index: Makefile.in
>> ===================================================================
>> --- Makefile.in (revision 1868723)
>> +++ Makefile.in (working copy)
>> @@ -934,6 +934,7 @@
>> @for f in $(SWIG_PY_SRC_DIR)/*.py $(SWIG_PY_DIR)/*.py; do \
>> ! [ -f "$$f" ] || cp -pf $$f $(SWIG_PY_DIR)/libsvn; \
>> done
>> + @cd $(SWIG_PY_DIR)/libsvn;ln -sf ../.libs/*.so .
>> @touch $(SWIG_PY_DIR)/libsvn/__init__.py
>>
>> swig-py: autogen-swig-py copy-swig-py
>> ]]]
>>
>
>
> Do I understand correctly that this is a workaround for a bug in Swig
> 3.0.9, that was fixed in 3.0.10?
Yes, with Python >= 2.7 + SWIG 3.0.9, libsvn.foo try to import C extension
module _foo from its relative path only, doesn't fall back to normal module
search path. This only affects on test. Also, the code of libsvn.foo
produced by SWIG 4.0 attempts relative import only (as far as it is imported
as `libsvn.foo', not as `foo'). So This patch also address to SWIG 4.0
(as there are other issues with SWIG 4.0, our code doesn't work yet, though).
> Because if that's the case, I would prefer
> making 3.0.10 our required minimum version. Remember that users who build
> from our tarballs do not need Swig on Unix, it's only needed by developers
> and the RM.
I see. I missunderstood it because ome downstream packager attempt to use
their own platform SWIG, at least on FreeBSD and Arch Linux make dependecy
to SWIG for their package building....
https://www.freebsd.org/cgi/ports.cgi?query=py27-subversion&stype=all&sektion=all
https://www.archlinux.org/packages/extra/x86_64/subversion/
Then, I think we should update subversion/bindings/INSTALL to mension
it is optional even for building swig language bindings.
> (N.b., we may have to include generated sources for both Python 2 and 3 in
> our tarballs, but that's a separate issue.)
>
>
>
> (On Windows, as far as I read win_tests.py, it copies modules
>>
> for test with same hierarchy as install time, so it doesn't
>> affect, I guess.)
>>
>
>
> Yes, Windows shouldn't be affected.
Ah, thanks for clearify it.
Cheers,
--
Yasuhito FUTATSUKI <futatuki_at_yf.bsdclub.org>/<futatuki_at_poem.co.jp>
Received on 2019-10-29 01:48:52 CET