On 2020/04/14 17:59, Branko Čibej wrote:
> On 14.04.2020 10:26, Stefan Sperling wrote:
>> On Tue, Apr 14, 2020 at 08:50:03AM +0200, Branko Čibej wrote:
>>> On 08.04.2020 12:18, Stefan Sperling wrote:
>>>> Everyone, thanks for all the contributions you have made for -rc2!
>>>> The 1.14.0-rc2 release artifacts are now available for testing/signing.
>>>> Please get the tarballs from
>>>> and add your signatures there.
>>>> If everything goes well we can rebrand this release candidate as
>>>> the actual 1.14.0 release with minimal effort.
>>>> The prospected 1.14.0 release date is May 6.
>>> Configure on OSX throws warnings about missing Swig for Python bindings.
>>> This is a regression. Swig should not be needed for release builds.
>> It's unclear from your message whether you consider this a release blocker.
> It's not a blocker. The swig-py build works fine and doesn't try to
> invoke Swig, but configure shouldn't warn, especially when
> --without-swig is passed explicitly. It doesn't for Ruby and Perl.
I agree that if --without-swig is passwed to configure, it shouldn't
check SWIG version for SWIG Python bindings even if the user want
to build Python bindings. Configure script also check SWIG version
for Ruby bindings. But its check concerns that SWIG_VERSION is empty,
so it's no problem.
The patch attached address only for the case --without-swig.
However I also want to fix still existiong problems below:
* When environment variable PYTHON is set for make check, configure also
treat it as a target of Python bindings, regardlessly the user really
want to build Python bindings or not. It is also check if py3c.h
* If SWIG generated Python bindings source files already exist on
configure and its target Python version is different from the target
provided for configure, force to regenerate bindings source files.
Yasuhito FUTATSUKI <futatuki_at_yf.bsdclub.org>/<futatuki_at_poem.co.jp>
Received on 2020-04-14 16:43:55 CEST