On Mon 28 Oct 2019, 15:11 Yasuhito FUTATSUKI, <futat...@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? 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.

(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.

-- Brane



>

Reply via email to