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

[Helmut Grohne]

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