[Development] moc output from non-local tool build

Joerg Bornemann joerg.bornemann at qt.io
Tue Sep 14 09:46:10 CEST 2021

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: 

> 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.



More information about the Development mailing list