I wouldn't mind adding/helping with adding/reviewing the necessary code to moc so that it has that compatibility support. I can certainly see the use case for it. However, I think there are still two things missing: - a confirmation from Jörg that the current hard dependency on the exact version can be avoided, else the whole thing becomes moot. Given the fact that we cmake has support for version ranges that should however be trivial, as long as we actually preserve compatibility (and accept the resulting maintenance burden). - some formal decision on how long that sliding window should be. 2 years sounds fine to me, but it might be better to express this in terms of Qt minor releases.
-- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- ________________________________________ Von: Development <development-boun...@qt-project.org> im Auftrag von Thiago Macieira <thiago.macie...@intel.com> Gesendet: Montag, 13. September 2021 22:13 An: development@qt-project.org Betreff: Re: [Development] moc output from non-local tool build On Monday, 13 September 2021 11:21:37 PDT Thiago Macieira wrote: > Your way is easier on the packagers, though, since the cross-compilations > are usually not critical content, but the host/native Qt is. But I don't > think it's the typical scenario for cross-compiling. People usually > download the sources in order to cross-compile Qt with their device's > toolchain and they'd like to use the system's Qt to help bootstrap. The > system's Qt is usually older. Ah, but for embedded device targets, one usually wants the best possible, so depending on your distro's older and crappier moc is not a good idea. Sounds to me like we should do both, with a 2-year sliding window of compatibility. My current changes require no extra effort (they're done anyway, will push soon). Adding the version arguments to the tools requires a bit more effort. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
