[Development] moc output from non-local tool build

Marius Kittler mkittler at suse.de
Mon Sep 13 18:13:02 CEST 2021

Am Freitag, 10. September 2021, 16:58:55 CEST schrieb Thiago Macieira:
> Qt 6 supports using the moc from a different build of Qt, to help with the
> bootstrapping issue and also so you don't always run a debug-mode moc in
> your debug builds of Qt.
> Is that moc required to be from the same Qt version as the Qt you're trying
> to build? Or is there a leeway in accepting slightly different builds?
> We haven't yet made changes to the moc output that would make it
> incompatible, but I am thinking of doing that now for plugins and I'd like
> to know if I have to keep compatibility with a slightly older moc. It's not
> a problem, I just want to know if this is required.

>From my GNU/Linux user/distributor perspective it would be great if the host 
moc could be slightly newer than the target Qt libs. So if the distribution 
upgrades the regular Qt package the cross packages (targeting mingw-w64 and 
Android) would still be usable until they're updated as well. I don't expect 
that there would be a big delay. So it would be sufficient if moc would be 
able to generate files which can still be used with the previous release of 
Qt, so moc from Qt 6.2.0 would be able to generate files for Qt 6.1.3 

To me it would make sense adding a CLI flag to moc to specify the target 
version and the CMake build scripts would pass it automatically (instead of 
rejecting the newer moc completely like it is currently implemented).

Of course all of this effort would be quite fruitless if other tools like uic 
would not support the same as well. Likely those tools are quite 
unproblematic. Maybe only the build system needs to be changed to accept newer 
host versions.

Alternatively it would also be interesting to provide a "tools only" build to 
be able to provide host tools of the required version. However, I actually 
like not having to build tools over and over again for every target so a 
"compatible" moc sounds much better to me.

More information about the Development mailing list