On 9/13/21 5:30 PM, Thiago Macieira wrote:
For a cross-build, currently, the host Qt needs to have the same version
as the target Qt. When trying to build, let's say, Qt for Android 6.2.0
with a host Qt 6.1.2, you're getting an error:
Could not find a configuration file for package "Qt6CoreTools" that is
compatible with requested version "6.2.0".
This is because our find_package calls for the host Qt contain the exact
version number of the Qt that is being built.
Fair enough, but then the question is whether that's intended or a simple
accident of how it was implementation.
I understand this version restriction as safety net that is supposed to
prevent pulling in incompatible Qt packages. If we drop it entirely,
it's even possible to pull in tools from different Qt builds that are
pointed to by CMAKE_PREFIX_PATH. Maybe Alexandru can shed more light on
this when he's back.
And I just realize that the version restriction only works in one
direction. It's possible to use Qt 6.2 as host Qt for 6.1 (if we ignore
failures due to the incompatible internal API).
BTW, is the functionality now working for non-crossing builds?
It's been implemented with cross-builds as ultimate goal, but it's been
used for documentation-only builds as well:
https://wiki.qt.io/Qt_Build_System_Glossary#Documentation-only_Build
I've been
trying to use the CMake Ninja multi-config setup, but it's very painful due to
lots of implementations issues.
> I'll have to go back to regular single-config
> and I don't want to use the local moc.
Not sure what you're getting at here. Ninja multi-config and
QT_HOST_PATH are orthogonal features. Have these implementation issues
been reported?
FWIW, in multi-config builds, with a recent enough CMake version, tools
are built in release config only.
Cheers,
Joerg
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
