[Pkg-tcltk-devel] Bug#919343: tdom FTCBFS: hard codes the wrong pkg-config, version graph

[Rolf Ade]

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