[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 15:30:24 +0200

On 16.04.2018 14:29, James McCoy wrote:
> On Mon, Apr 16, 2018 at 10:42:31AM +0200, Branko Čibej wrote:
>> [Moved from users@]
>> On 16.04.2018 10:36, Branko Čibej wrote:
>>> 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?
> I did some searching to see if I could find any discussion that led me
> to making this change and didn't turn up anything. I assume I was
> missing the context of the Swig bindings being pre-generated.
> Maybe we should have some automated testing for the peculiarities of
> release tarballs to avoid mistakes like this in the future?

We do, it's called release testing, but in my case, for example, I
always have "--with-swig" there ... and swig installed ... because I
test on my development machine. So the upshot is that at least I could
possibly test this better by using --without-swig for the release
tarballs (I'll have to check what that actually does).

> Reverted in r1829260.

Ok ... please make a backport proposal for 1.10.x.

-- Brane
Received on 2018-04-16 15:30:31 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.