Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)
On Mon, Apr 16, 2018 at 03:30:24PM +0200, Branko Čibej wrote: > 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, That's not automated. :) Especially since this is a known peculiarity, it might be useful to have one bot generate a release tree (assuming our tooling for that is independent from tagging), uninstall swig, and then build. > > Reverted in r1829260. > > Ok ... please make a backport proposal for 1.10.x. Done. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)
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
Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)
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
Re: Strange libtool errors when try to build pyhton and ruby bindings (1.10.0)
[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
