[Pkg-cmake-team] Bug#1032413: kodi-inputstream-adaptive FTCBFS: assumes a toolchain file

[Helmut Grohne]

Hi Vasyl,

This is interesting, so I loop in a few more recipients.

On Mon, Mar 06, 2023 at 11:26:51AM +0000, Vasyl Gello wrote:
> I reproduced the behavior and it appears that the CMake project for kodi-inputstream-adaptive is instantiated correctly,
> but the external project for embedded Bento4 is not. I encountered the same issue with libdate-tz in src:kodi, but there
> I ended up building libdate-tz prior to configuring Kodi build. I think we can either ask CMake to generate a toolchain file
> or apply your patch (yet I'd pass only a toolchain file if its specified).

Let me take the opportunity to give a brief history of why we do things
the way we do it.

In the earlier days of cross building, we got autoconf work with
debhelper rather early and eventually got into cmake. At that time,
creating a temporary file in debhelper was kinda non-trivial and it was
easier to just add options to command lines (such as cmake). We also
noticed that some projects (I happen to not remember which) would behave
surprisingly when faced with a toolchain file. The forms were completely
different behaviour as their upstreams considered cross building a
special case where you could only ever build a tiny fraction of the
project with automatically reduced functionality (which we don't want)
or failing if the toolchain file were missing just one of a lot of
settings even if that technically wasn't necessary. So back then, we
opted to let dh_auto_configure pass tons of -D flags to cmake when it
detects a cross build. That's how it happened and not how it must be
done for eternity.

A while later meson came along and when adding support for it, we
actually created a "crossfile" (how meson calls it) and pass that. That
option certainly is on the table. Another major difference here is that
the tool that creates this crossfile currently is a script debcrossgen
in the meson package and we can change this crossfile generator without
touching debhelper. For cmake, we've essentially inlined this into
Debian::Debhelper::Buildsystem::cmake, so whenever we need to change a
cmake cross compilation flag, we need a debhelper upload, which is
suboptimal.

So yeah, I recognize that a toolchain file probably is the more common
way of cross building cmake projects and maybe we should switch to that
model. We've got around 2700 source packages that would be affected and
a fair number of them has quite long build times (not counting tests),
so we'd need a bit of preparation. Other than that, I think we could
consider that. The approach probably would be:

1. Add a Debian-specific toolchain file generator to the cmake binary
   package. This would probably be some shell script or similar and be
   maintained inside Debian as it is really specific to how Debian puts
   together its packages.

2. Prepare a debhelper patch that makes it use this toolchain generator
   and passes a toolchain file instead of all of its options.

3. Perform a test build with the patched debhelper together with a
   reference build to see what breaks and evaluate.

4. Once confident, upload debhelper.

Questions from my side:

a) Would the cmake maintainers be interested/willing in maintaining this
   toolchain generator?

b) Is this change worth the effort? Are there sufficiently many packages
   that would improve?

c) The way we currently pass all the flags makes them show up in build
   logs. That helps debugging cross compilation problems. Should
   debhelper dump the toolchain file to the build log?

d) A number of projects need to build native tools. A very common way of
   achieving that is using an ExternalProject and passing
   architecture-independent aspects along notably excluding the compiler.
   How does this change affect them? (Answered by step 3.)

Given that this is quite some effort, I am wondering whether adapting
kodi is the cheaper way. This kinda is a "time travel fix". We'd
probably have done it differently if we'd start now.

And yeah, none of this is relevant to bookworm (including my kodi
patches).

Helmut