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
