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
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
