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. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
