RE: Cygport: How to add -I m4 to autoreconf / aclocal? (issue with building mingw64-x86_64-gtksourceview3.0-3.24.6 )
Dear Hans-Bernhard, > There is indeed a general bug in the original source that requires fixing. > The > following line is sorely missing from the top-level > Makefile.am: > > ACLOCAL_AMFLAGS = -I m4 thanks a lot for taking the time to investigate this! I will suggest this change to the gtksourceview team. Should I meanwhile prepare a patch for Cygwin, so that the package can be compiled again (as I said it has a severe bug which is fixed upstream), or would you prefer to wait for the upstream change? Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Re: Cygport: How to add -I m4 to autoreconf / aclocal? (issue with building mingw64-x86_64-gtksourceview3.0-3.24.6 )
Am 06.06.2019 um 21:18 schrieb Hans-Bernhard Bröker: > Still that would constitut, if not a flat-out bug, at least severe > bit-rot in the upstream package, because if it doesn't work with > Cygwin's automake version 1.15, it most likely doesn't with reasonably > current versions of automake on other platforms, either. After some actual inspection, and a bit of RTFMing, things became clearer. There is indeed a general bug in the original source that requires fixing. The following line is sorely missing from the top-level Makefile.am: ACLOCAL_AMFLAGS = -I m4 It doesn't look like this should be buildable without that line, on any other platform. If it does, their gnome-autogen.sh must be rather different from Cygwin's. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Cygport: How to add -I m4 to autoreconf / aclocal? (issue with building mingw64-x86_64-gtksourceview3.0-3.24.6 )
Dear Hans-Bernhard, thanks for sharing your thoughts on this! One more note: in the latest version of the configure file for gnome 3.24 from May 6th 2019: https://github.com/GNOME/gtksourceview/blob/gnome-3-24/configure.ac the problematic AX_REQUIRE_DEFINED([GTK_CHECK_BACKEND]) is still in. So I think it is not that likely that this doesn't build on recent Linux. I will contact the gtksourceview team and ask for their opinion. Possibly one can agree to simply remove these superfluous and problematic checks. Also I will simply try it on a recent Ubuntu. I will report the outcome here. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Re: Cygport: How to add -I m4 to autoreconf / aclocal? (issue with building mingw64-x86_64-gtksourceview3.0-3.24.6 )
Am 06.06.2019 um 10:03 schrieb Soegtrop, Michael: > From a tarball. As far as I can tell I am exactly reproducing the > original package that is available as binary on Cygwin repos with > exactly the same sources, patches and cygport file. ... but possibly way different versions of the autotools compared to those the package was built with, back then. > I can't judge this and would need some advice here. The issue could > be at several places: > > - In the past and on other systems aclocal automatically included the > package local m4 folder in all process steps. Possible. Automake may have changed in that regard, at some point. Still that would constitut, if not a flat-out bug, at least severe bit-rot in the upstream package, because if it doesn't work with Cygwin's automake version 1.15, it most likely doesn't with reasonably current versions of automake on other platforms, either. > - In the past cygport automatically added an option to autoreconf to > include the local m4 folder. I rather doubt that. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Cygport: How to add -I m4 to autoreconf / aclocal? (issue with building mingw64-x86_64-gtksourceview3.0-3.24.6 )
Dear Hans-Bernhard, > Are we building this from a tarball, or directly off the bleeding edge? From a tarball. As far as I can tell I am exactly reproducing the original package that is available as binary on Cygwin repos with exactly the same sources, patches and cygport file. > If that had to be done, that would constitute a clear upstream bug. > Well, either that or that file itself should not be there. I can't judge this and would need some advice here. The issue could be at several places: - In the past and on other systems aclocal automatically included the package local m4 folder in all process steps. If this is the intended behavior of aclocal, this is a regression in current cygwin's aclocal package are some of the packages it requires. - In the past cygport automatically added an option to autoreconf to include the local m4 folder. - The original builder/maintanier of the current package mingw64-x86_64-gtksourceview3.0-3.24.6 did something non-standard to get the package build (that is didn't just run cygport ... all. - The use of AX_REQUIRE_DEFINED in gtksourceview configure.ac for macros defined in the package local m4 folder is bogus. This would then be a gtksourceview upstream bug, as you suggest. One can argue that it doesn't make a lot of sense to check the availability of locally supplied macros, but one can also ask why it seems to work on other systems and seems to have worked on Cygwin in the past. Best regards, Michael Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
