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