Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph
After some more testing applied your patch. Thanks.
Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph
Hi Rolf, On Fri, Jan 18, 2019 at 02:48:52PM +0100, Rolf Ade wrote: > Sorry for being dense but I haven't got this. If you cross-compilie, > you build for a specific target platform, no? How could that be > unspecified? Do you say that cross-compiling doesn't/can't work > regardless of the build/target platform combination? Or, again, what > concrete task is falling? (Something like "building tDOM on linux with > mingw-xy for target xyBSD/win64/whatever does fail with 0.9.1 but is > successful with the patch") I guess this is a misunderstanding. "target" only matters for compilers. The target is what architecture the resulting tdom operates on, not where it runs. The thing where you want to run it is called "host" and for cross compilation "build" differs from "host". Which "host" you use does not matter for the sake of this bug, because it is reproducible whenever the build architecture differs from the host architecture (i.e. a cross build). > From reading your patch and digging around in some documentation it's > about the executable name of pkg-config. Does this do just string > operations or does it actually look up an executable with that name > and complains in some way, even if the user doesen't use > --enable-html5? Yes, when cross compiling, you usually prepend the host architecture (called $ac_tool_prefix) to architecture-dependent tools (like pkg-config). By prepending the architecture, you specify which architecture you want a library for. A failure to find pkg-config will simply result in the PKG_CONFIG variable being empty here. > Or in other words: If a user doesn't have pkg-config installed and > build tDOM with default configure switches (--enable-html5 isn't > default) - no cross-compiling in the picture - then this works with > 0.9.1. Does this still work with your patch (without user visible > complains)? Like before, it should figure that pkg-config is not usable and simply build with reduced feature set. > Yes, tDOMs aclocal.m4 is "hand-writen". While digging around, I see > notes in the alocal info documentation things like: > > "We recommend against using ‘acinclude.m4’ in new packages." > > Instead, they recommend something else. Since I'm using the build > frame work from the sampleextension of the Tcl Extension Architecture > (TEA) I've two sets of "local" macros: the generic TEA macros and the > in fact local additional tDOM macros, so things probably would have to > be adapted a bit. > > But I also read in the automake.info: > > "‘aclocal’ is expected to disappear." Uh. Tht was news to me. I'm actually unsure now what the proper solution is. > Given the --enable-html5 (pkg-config executable name) problem while > cross-building is saved (say, by your patch) what benefit do I get to > adapt the build system so that (probably disappearing) aclocal tool > may be able to regenerate aclocal.m4? There is an advantage to get, but I'm not sure that it requires aclocal: By using macros like PKG_CHECK_MODULES, you can simplify your macros. Usually, using upstream macros like this "just works". I don't actually understand, why it isn't picked up in the case of tdom and I attributed that to aclocal. Maybe I'm wrong here and the cause is something else. > Sorry (again) that turns out to be much more complicated than you > probably expected for such a simple (and from your viewpoint probably > obvious) patch. It's just that I enjoy the luxury in my open source > projects to at least basically understand the changes that I'm doing > (instead of 'builds and runs locally, that's enough'). That's fine. You're the one who will likely deal with potential bugs in my patch, so it seems wise to understand it before accepting it. I'm doing the same in projects I maintain. Helmut
Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph
Hi Helmut, Am 01/18/2019 06:27 AM, Helmut Grohne wrote: On Thu, Jan 17, 2019 at 11:03:26PM +0100, Rolf Ade wrote: Could you please be a bit more specific about the problem: tDOM with which configure flags cross-compilied on what platform for which target platform does not build? If only to give me a chance to check that your patch fixes the problem. The configure flags are selected by the Debian package. You can find them in debian/rules: https://sources.debian.org/src/tdom/0.9.1-1/debian/rules/#L29 Thanks. I perform all such QA builds on amd64. The target architecture is left unspecified, because tdom does not evaluate it as it is not a compiler. Sorry for being dense but I haven't got this. If you cross-compilie, you build for a specific target platform, no? How could that be unspecified? Do you say that cross-compiling doesn't/can't work regardless of the build/target platform combination? Or, again, what concrete task is falling? (Something like "building tDOM on linux with mingw-xy for target xyBSD/win64/whatever does fail with 0.9.1 but is successful with the patch") From reading your patch and digging around in some documentation it's about the executable name of pkg-config. Does this do just string operations or does it actually look up an executable with that name and complains in some way, even if the user doesen't use --enable-html5? Or in other words: If a user doesn't have pkg-config installed and build tDOM with default configure switches (--enable-html5 isn't default) - no cross-compiling in the picture - then this works with 0.9.1. Does this still work with your patch (without user visible complains)? [...] I've to confess that for the build system I mostly cargo cult TEA. Could you please explain in short how "tdom confuses the meaning of aclocal.m4 and acinclude.m4 and therefore [you] cannot run aclocal"? aclocal.m4 and acinclude.m4 serve different needs. The former is meant to be generated by aclocal. It scans macro archives from upstream projects and embeds those macros that tdom needs into a long aclocal.m4. acinclude.m4 is meant as an additional file, which is not replaced by aclocal, but rather included by aclocal. tdom's aclocal.m4 doesn't look like it was generated by aclocal to me. The autoconf manual has a few words along the same lines: https://www.gnu.org/software/automake/manual/html_node/Complete.html For using macros like PKG_CHECK_MODULES or PKG_PROG_PKG_CONFIG from pkg-config's pkg.m4, we need aclocal to copy them to aclocal.m4 as far as I understand. Using PKG_CHECK_MODULES is particularly useful, because it condenses a lot of functionality in a single call: PKG_CHECK_MODULES([HTML5],[gumbo],[AC_DEFINE(TDOM_HAVE_GUMBO)],[]) For the static case, a similar call to PKG_CHECK_MODULES_STATIC can be used. The call above will create variables HTML5_CFLAGS and HTML5_LIBS and will automatically AC_SUBST them considerably shortening your m4 code in addition to just working correctly for cross compilation. Yes, tDOMs aclocal.m4 is "hand-writen". While digging around, I see notes in the alocal info documentation things like: "We recommend against using ‘acinclude.m4’ in new packages." Instead, they recommend something else. Since I'm using the build frame work from the sampleextension of the Tcl Extension Architecture (TEA) I've two sets of "local" macros: the generic TEA macros and the in fact local additional tDOM macros, so things probably would have to be adapted a bit. But I also read in the automake.info: "‘aclocal’ is expected to disappear." Given the --enable-html5 (pkg-config executable name) problem while cross-building is saved (say, by your patch) what benefit do I get to adapt the build system so that (probably disappearing) aclocal tool may be able to regenerate aclocal.m4? Sorry (again) that turns out to be much more complicated than you probably expected for such a simple (and from your viewpoint probably obvious) patch. It's just that I enjoy the luxury in my open source projects to at least basically understand the changes that I'm doing (instead of 'builds and runs locally, that's enough'). Thanks rolf
Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph
Hi Rolf, On Thu, Jan 17, 2019 at 11:03:26PM +0100, Rolf Ade wrote: > Could you please be a bit more specific about the problem: tDOM with > which configure flags cross-compilied on what platform for which > target platform does not build? If only to give me a chance to check > that your patch fixes the problem. The configure flags are selected by the Debian package. You can find them in debian/rules: https://sources.debian.org/src/tdom/0.9.1-1/debian/rules/#L29 I perform all such QA builds on amd64. The target architecture is left unspecified, because tdom does not evaluate it as it is not a compiler. > If I patch tDOM with your code it still builds correct for me (with > --enable-html5, which, from your patch, do you use and is the culprit, > and without and so on). So I'm somewhat tempted to check-in, if I have > evidence that this does otherwise good. That's intended. The patch is written in a w way to minimize the potential to affect native builds. Unless you perform a cross build, it'll continue to use plain pkg-config like before. > I've to confess that for the build system I mostly cargo cult TEA. > Could you please explain in short how "tdom confuses the meaning of > aclocal.m4 and acinclude.m4 and therefore [you] cannot run aclocal"? aclocal.m4 and acinclude.m4 serve different needs. The former is meant to be generated by aclocal. It scans macro archives from upstream projects and embeds those macros that tdom needs into a long aclocal.m4. acinclude.m4 is meant as an additional file, which is not replaced by aclocal, but rather included by aclocal. tdom's aclocal.m4 doesn't look like it was generated by aclocal to me. The autoconf manual has a few words along the same lines: https://www.gnu.org/software/automake/manual/html_node/Complete.html For using macros like PKG_CHECK_MODULES or PKG_PROG_PKG_CONFIG from pkg-config's pkg.m4, we need aclocal to copy them to aclocal.m4 as far as I understand. Using PKG_CHECK_MODULES is particularly useful, because it condenses a lot of functionality in a single call: PKG_CHECK_MODULES([HTML5],[gumbo],[AC_DEFINE(TDOM_HAVE_GUMBO)],[]) For the static case, a similar call to PKG_CHECK_MODULES_STATIC can be used. The call above will create variables HTML5_CFLAGS and HTML5_LIBS and will automatically AC_SUBST them considerably shortening your m4 code in addition to just working correctly for cross compilation. Hope this helps Helmut
Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config,version graph
Could you please be a bit more specific about the problem: tDOM with which configure flags cross-compilied on what platform for which target platform does not build? If only to give me a chance to check that your patch fixes the problem. If I patch tDOM with your code it still builds correct for me (with --enable-html5, which, from your patch, do you use and is the culprit, and without and so on). So I'm somewhat tempted to check-in, if I have evidence that this does otherwise good. I've to confess that for the build system I mostly cargo cult TEA. Could you please explain in short how "tdom confuses the meaning of aclocal.m4 and acinclude.m4 and therefore [you] cannot run aclocal"?
Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config
Source: tdom
Version: 0.9.1-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
tdom fails to cross build from source, because and autoconf macro hard
codes the build architecture pkg-config. In principle, one should be
using PKG_PROG_PKG_CONFIG or even PKG_CHECK_MODULES here, however that's
not possible, because tdom confuses the meaning of aclocal.m4 and
acinclude.m4 and therefore we cannot run aclocal. It would be a good
idea to fix that as well. Therefore, the attached patch resorts to a
more bare bones fixes. Please consider applying it.
Helmut
--- tdom-0.9.1.orig/tdom.m4
+++ tdom-0.9.1/tdom.m4
@@ -225,6 +225,7 @@
#
AC_DEFUN(TDOM_ENABLE_HTML5, [
+AC_PATH_TOOL([PKG_CONFIG],[pkg-config])
AC_MSG_CHECKING([whether to enable support for HTML5 parsing (using gumbo)])
AC_ARG_ENABLE(html5,
AC_HELP_STRING([--enable-html5],
@@ -241,24 +242,22 @@
HTML5_INCLUDES=""
if test "$tcl_ok" = "yes" ; then
# Check if pkg-config is available
-PKGCONFIG=no
-pkg-config --version > /dev/null 2>&1 && PKGCONFIG=yes
-if test "$PKGCONFIG" = no; then
+if test "x$PKG_CONFIG" = x; then
tcl_ok=no
AC_MSG_ERROR([cannot find pkg-config needed for --enable-html5.])
fi
fi
if test "$tcl_ok" = "yes" ; then
-HAVEGUMBO=`pkg-config --exists gumbo && echo "1"`
+HAVEGUMBO=`$PKG_CONFIG --exists gumbo && echo "1"`
if test "$HAVEGUMBO" = "1" ; then
AC_MSG_RESULT([yes])
AC_DEFINE(TDOM_HAVE_GUMBO)
if test "${TEA_PLATFORM}" = "windows" ; then
-HTML5_LIBS="-Wl,-Bstatic `pkg-config --static --libs gumbo` -Wl,-Bdynamic"
+HTML5_LIBS="-Wl,-Bstatic `$PKG_CONFIG --static --libs gumbo` -Wl,-Bdynamic"
else
-HTML5_LIBS="`pkg-config --libs gumbo`"
+HTML5_LIBS="`$PKG_CONFIG --libs gumbo`"
fi
-HTML5_INCLUDES="`pkg-config --cflags gumbo`"
+HTML5_INCLUDES="`$PKG_CONFIG --cflags gumbo`"
else
AC_MSG_ERROR([The required lib gumbo not found])
fi
