subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James McCoy <>
Subject Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)
Date Mon, 16 Apr 2018 12:29:42 GMT
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?

Reverted in r1829260.

GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

View raw message