qt6: add ability to crossbuild

[jcar87]

Summary

Changes to recipe: qt/6.x.x

Motivation

Provide ability to cross-build recipe

Details

• Preserve Qt6HostInfoConfig.cmake in the package folder - this is needed by Qt itself when crossbuilding (it does not define targets, just some meta-information about the build)
• Define QT_HOST_PATH to point to the self-dependency in the build context
• In lieu of Qt6CoreTools - simply pre-include the target executable information that is already in the dependency in the build context - that will define things like Qt6::moc and will use those instead
• Include executables part of Qtbase tools that were not defined in the targets file - these are needed when crossbuilding qt
• Delete logic around android_sdk (is not an option)
• Minimally adapt the test_package to get it to work when cross-building (it's subject to further changes in the future)

Tested on

• macOS arm64 -> x86_64 (should be on CI too)
• Linux aarch64 -> x86_64

Android may require additional work, as it requires an SDK setup (and not just the NDK). Not invalidating this, as it may be possible to inject the necessary variables via tools.cmake.cmaketoolchain:extra_variables to get a successful build

Close #20257
Close #8120

---

• Read the contributing guidelines
• Checked that this PR is not a duplicate: list of PRs by recipe
• Tested locally with at least one configuration using a recent version of Conan

[jcar87]

qt-crossbuild-log.txt

Log for Linux x86_64 -> armv8 build

[valgur]

Thanks!

Did you also manage to cross-compile a recipe consuming the cross-compiled Qt? I think it might have required some additional steps to get it working.

I would also recommend deprecating the cross_compile and sysroot options in the recipe. I've forgotten some of the details, but I think they were mostly a holdover from the Qt5 recipe and mostly useless for this one. sysroot should also be handled by the tools.build:sysroot config option instead.

Cross-compilation support for optional but important modules like QtDeclarative needs some additional work as well. In particular, you'll have to make sure that the optional module is enabled correspondingly in the Qt tool_requires, so that the tools for the modules are built correctly, and also tweak package() to make sure that they are handled correctly.

I'll probably open a PR for the last issue at some point.

[valgur]

Also - how did you handle the xorg/system and opengl/system dependencies for cross-compilation? I assume you provided them somehow?

Edit: nevermind, I now saw that you cross-compiled for x86_64, which sidesteps this issue.

[jcar87]

Did you also manage to cross-compile a recipe consuming the cross-compiled Qt? I think it might have required some additional steps to get it working.

We are able to crossbuild qt-advanced-docking-system with the changes from this PR

Edit: nevermind, I now saw that you cross-compiled for x86_64, which sidesteps this issue.

We've done both, cross armv8->x86_64 and x86_64 -> armv8 - in both cases we are using Desktop OpenGL and x11, as provided by Ubuntu. This docker image can be used as an example: https://github.com/jcar87/cci-crossbuild-example - I reckon something like this would work:

# build Qt for the local architecture, incl. all dependencies
conan create recipes/qt/6.x.x --version=6.7.3 --build=missing -c tools.system.package_manager:mode=install

# build Qt for the target architecture, incl. all dependencies,
# --build=missing --build="missing:qt/*" is needed to avoid re-building the build context qt
conan create recipes/qt/6.x.x --version=6.7.3 --build=missing --build="missing:qt/*" -pr arm64  -c tools.system.package_manager:mode=install

For system dependencies when crossbuilding, we roughly see the following cases:

• When working on a multiarch debian, it is possible to rely on Conan to install the packages for the "foreign" architecture, provided dpkg and the apt sources are correctly configured to support this (the dockefile linked above is an example of how to do this for a recent ubuntu). When using the Debian/Ubuntu provided cross-compiler, the sysroot is implicitly / (does not require an additional flag), and all "system" paths are correctly configured for the target architecture - however it's important to use a variant of pkg-config that also is
• when working with a sysroot (--sysroot is passed to the compiler, e.g. with tools.build:sysroot) - this will depend on what the actual target platform is and what functionality the user requires. If the user requires xorg / desktop opengl - this should be pre-installed in the sysroot. We would expect this to be the case when targeting something like Raspberry Pi or Jetson, that the .pc files are also in the sysroot. This will require a properly configured pkg-config, and the tools.system.package_manager:mode in the host context to bypass the build machine (report or report-installed should do it )
• if an implicit sysroot (e.g. from an SDK), or an explicit sysroot (--sysroot) already provide EGL/x11 or any other library, but does not provide .pc files, this is not much different than "system_libs": everything is already in the default search path and no additional flags are required other than the library names - however mileage may vary here if tools expect a .pc file and can't fall back on defaults. When they can fall back, the [platform_requires] here may be useful to tell Conan that */system requirements already installed and the logic in the recipes can be bypassed - but that feature is still experimental. But again, I'd caution users to not pay for what they don't use - and consider that recipes in Conan Center index likely enable far more optional dependencies than they actually require.