[Development] moc output from non-local tool build

[Joerg Bornemann]

On 9/14/21 12:11 PM, Marius Kittler wrote:
> Am Dienstag, 14. September 2021, 09:51:21 CEST schrieb Joerg Bornemann:
>> The maintenance burden is next level. This would mean to keep all
>> internal API that's used in lib/cmake compatible. Apparently forward and
>> backward if I read your requirements correctly.
>>
> 
> I'm afraid that's the next challenge, indeed. I've recently tried to use host
> Qt 6.2 (beta) with Qt 6.1.3 targeting mingw-w64 and it also broke because it
> couldn't find some CMake functions. One would have expected that this isn't a
> problem because my host Qt was newer but apparently its configuration files
> are not self-contained and try to call helper functions from the target Qt
> instead of "staying in the host world". But would be "staying in the host
> world" problematic? I suppose it comes with the challenge of avoiding name
> clashes between the host and target worlds but I guess it should be doable.

I think what you're seeing is the missing function 
__qt_internal_promote_target_to_global in that case. That function is 
used in exports (the host Qt) and in the actual build too (target Qt).

The "right solution" probably would be a completely separated API for 
exports such that imported Qt packages can stay in their world.

A pragmatic makeshift solution could be to backport such functions, 
maybe as empty stubs, once such failures are identified.

And of course, we need some kind of test coverage or things are bound to 
regress.


Cheers,

Joerg