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
