[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)

From: Branko Čibej <brane_at_apache.org>
Date: Mon, 16 Apr 2018 10:42:31 +0200

[Moved from users@]

On 16.04.2018 10:36, Branko Čibej wrote:
> On 15.04.2018 21:30, Branko Čibej wrote:
>> On 13.04.2018 18:20, Lev Serebryakov wrote:
>>> I'm preparing FreeBSD of subversion-1.10.0 and have very strange errors
>>> when try to build bindings.
>>>
>>> subversion itself builds without problems.
>> I just created a FreeBSD 11 virtual machine tried building the 1.10.0
>> source tarball and ... well, I can confirm this report. I couldn't build
>> the Perl bindings either, due to a missing header.
>>
>> However, when I installed autoconf, libtool and swig30, and started with
>> a clean tree (make extraclean; ./autogen.sh; ./configure ...), I could
>> build JavaHL and all the Swig bindings — with the standard deluge of
>> missing typemap warnings. I could run the Perl, Python and JavaHL tests,
>> but not the Ruby tests, the latter apparently due to a missing dependency.
>>
>> It makes me wonder what went wrong with the build scripts generation in
>> the release package, because the builds worked fine on Linux, macOS and
>> OpenBSD. The other possibility is that FreeBSD is simply weird ...
> The problem is that Swig has become a build-time dependency now. We
> don't configure the Swig bindings unless Swig is installed, even if the
> binding sources are already generated — as they are in the release tarballs.
>
> The solution is to install Swig and tell configure about it:
>
> $ sudo pkg install swig30
> $ ./configure --with-swig=/usr/local/bin/swig30 ...
>
>
> This will not cause the Swig sources to be regenerated, but will perform
> the proper configuration to make them compile correctly.
>
> I consider this to be a bug in our build scripts, FWIW.

I tracked this down to r1751167, which is only on trunk and 1.10.x.

Long story short: it is wrong to require swig in order to configure the
swig bindings. The whole point of putting generated swig wrappers into
the release tarballs is so that users can build them without having to
install swig.

Defining the symbols SWIG_PY_COMPILE, SWIG_RB_COMPILE, and so on, should
depend on the various scripting languages being installed, not on the
presence of Swig.

Can anyone explain the reasoning behind this change?

-- Brane
Received on 2018-04-16 10:42:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.