[package] qt/6.x: Qt 6 can not be cross-compiled

[petermbauer]

Description

Since there is a check implemented in validate() and setting the QT_HOST_PATH CMake variable is not implemented, it is not possible to cross-compile Qt, e.g. for x86_64 on an Apple Silicon machine.

Package and Environment Details

• Package Name/Version: qt/6.5.2
• Operating System+version: MacOS
• Compiler+version: XCode 14

Conan profile

[settings]
os=Macos
os_build=Macos
arch=x86_64
arch_build=armv8
compiler=apple-clang
compiler.version=14
compiler.libcxx=libc++
build_type=Release
[options]
[conf]
[build_requires]
[env]

Steps to reproduce

conan install --build missing qt/6.5.2

Logs

not relevant

[jwillikers]

Aww yes, won't the Qt recipe effectively have to add itself as a tool_requires when cross-compiling? The Wayland recipe works like this.

[petermbauer]

Aww yes, won't the Qt recipe effectively have to add itself as a tool_requires when cross-compiling? The Wayland recipe works like this.

This would already be in place: https://github.com/conan-io/conan-center-index/blob/master/recipes/qt/6.x.x/conanfile.py#L396-L397
But at least two more changes are needed:

• set QT_HOST_PATH via CMake to the installation folder of the tool_requires package so the tools like moc are taken from this "Host Qt"
• depending on which kind of cross-building is done, set QT_FORCE_BUILD_TOOLS=ON so the tools like moc are also built. Not sure if this can be determined automatically or if this should be implemented as an option.

I prepared the changes here

[jwillikers]

Nice, I didn't know that we already added it as a tool_requires. That QT_HOST_PATH setting is of course needed. With your changes, you'll want to set QT_HOST_PATH using the same condition for the tool_requires, i.e. if cross_compiling.

Since Qt is available as a tool_requires, why would QT_FORCE_BUILD_TOOLS be necessary?

[petermbauer]

Since Qt is available as a tool_requires, why would QT_FORCE_BUILD_TOOLS be necessary?

This is needed so the tools will also be built for the target platform. Otherwise there will be no moc etc. in the binary package being built so this Qt could not be used for development on the target platform. I came across this when building for x86_64 on an Apple Silicon machine. With Rosetta, the tools cross-compiled for Intel Macs can also be executed, but they would not be built without the flag being set.

[jwillikers]

Ah, I see. It's because the qttools option defaults to False. Do you think you could see if setting self.options.qttools = can_run(self) in the config_options(self) method allows you to omit the QT_FORCE_BUILD_TOOLS environment variable? That would be ideal if it works.

[petermbauer]

Ah, i did not recognize the "module options" yet, thanks! Pushed it and hope to be able to try it out tomorrow on a Mac.

[ericLemanissier]

It' not related to qttools. Moc, qmake, uic etc are part of qtbase. Is there an adverse effect of defining QT_FORCE_BUILD_TOOLS in all cross_compilation cases?

[petermbauer]

As i understand the documentation, the tools built for the target platform would be used for building the rest of Qt. This would mean that the tools need to be executable on the build platform too, which may not be the case.
But i have not tried it out so its just a guess.

[actondev]

The QT_HOST_PATH seems to be fixed by #21263 but there's still the following in there

        if cross_building(self):
            raise ConanInvalidConfiguration("cross compiling qt 6 is not yet supported. Contributions are welcome")

When disabling this I'm having the following issue

-- Configuring submodule 'qtbase'
CMake Error at qtbase/cmake/QtPublicDependencyHelpers.cmake:216 (find_package):
  Could not find a package configuration file provided by "Qt6HostInfo" with
  any of the following names:

    Qt6HostInfoConfig.cmake
    qt6hostinfo-config.cmake

  Add the installation prefix of "Qt6HostInfo" to CMAKE_PREFIX_PATH or set
  "Qt6HostInfo_DIR" to a directory containing one of the above files.  If
  "Qt6HostInfo" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  qtbase/cmake/QtBuild.cmake:578 (_qt_internal_find_host_info_package)
  qtbase/cmake/QtSetup.cmake:350 (include)
  qtbase/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake:265 (include)
  qtbase/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake:427 (qt_build_internals_set_up_private_api)
  qtbase/CMakeLists.txt:127 (qt_build_repo_begin)

@ericLemanissier do you perhaps have any insights since you worked in this recently?

[ericLemanissier]

@actondev see #21037 (comment) and following messages