[Development] moc output from non-local tool build

[Volker Hilsheimer]

> On 4 Nov 2021, at 17:46, Joerg Bornemann <Joerg.Bornemann at qt.io> wrote:
> 
> On 10/29/21 11:43 AM, Joerg Bornemann wrote:
> 
>>>> With https://codereview.qt-project.org/c/qt/qtbase/+/378053 it's now
>>>> possible to turn off the package version check and to use moc of a
>>>> different Qt version.  This requires that moc stays either compatible or
>>>> handles that /version argument outlined elsewhere in this thread.
>>> 
>>> Which is great, and is what I want, but we still need a decision on how long
>>> the compatibility window will be and how we will inform the tools of what
>>> version we're asking for.
>> A sliding window of two years has been proposed in this thread. Assuming two minor version bumps per year, that's four minor versions. Let's make that an odd number and we get the following
>> Proposal 1:
>> Qt 6.X should work with host tools of Qt 6.Y, where X-2 <= Y <= X+2
>> That's quite some commitment.
>> How about
>> Proposal 2:
>> Qt 6.X should work with host tools of Qt 6.Y, where X-1 <= Y <= X+1
>> That gives us less to test, and the sliding window is something like 1.5 years.
> 
> Any comments on the sliding window size?
> 
> Apart from that, after internal discussion I have to lower expectations regarding our commitment to this.  I don't see us creating the test infra for testing the build of different host/target Qt combinations. As such we offer no commitment or support, but we will accept patches that improve the situation
> 
> As to the question "how we will inform the tools of what version we're asking for": one way is to add -compat-version switches to the tools that need them.  The downside here is that this needs to be done the day before yesterday for all tools that contribute to the build.
> 
> Another way would be to load it onto the user to set an environment variable QT_TOOL_COMPAT_VERSION or such that is read by tools that need to.

Does anyone other than developers of Qt (and for us this could be a real time saver!) really need and benefit from this? I’d rather not want to ask our support team to support customers and users with a colorful blend of moc and library versions.

If not, then supporting the moc from the latest released series to be able to work with dev seems to be sufficient, doesn’t it? If I can reliably use Qt 6.2’s moc to build dev, and don’t have to worry that an ever-so-light-touching of QtCore ends up with rebuilding a world of moc files, then that’d be a real win. Ditto for cross compilation. If you don’t work on Qt, then I’d assume that you have Qt host tools from a package installed for the versions you need anyway.

And then it can be on a “best effort” level; there’ll be some surprises, just as there sometimes are surprises if your qtdeclarative test fails because you’re building against today’s qtbase, and if people that feel that pain fiercely enough come up with a test rig that catches such glitches during CI, then great. But it’s not exactly a blocker either.

Volker