El martes, 13 de noviembre de 2018 19:56:29 -03 Thiago Macieira escribió: > On Tuesday, 13 November 2018 13:43:20 PST Lisandro Damián Nicanor Pérez > Meyer > wrote: > > a) Qt 5 and Qt 6 binaries should be coinstalable both in a developer > > (libraries + binaries + build tools) and in a user's (only required > > libraries and binaries) perspective. For example: a user should not need > > qmake to be present. > > This does not apply for "application" executables that retain backwards > compatibility functionality. There's no need to version linguist, designer, > assistant or qdbus, qdbusviewer, so long as those applications can still be > used while developing Qt 5 applications.
Agreed, but this means that if an application is backwards compatible then it must be kept like that for all the Qt 6 lifetime. Is that feasible? And I could even stretch it a little more, at least just "for the fun of it": it might also mean to keep backwards compatibility in Qt n with n > 6. Why? Because some libs that depend on Qt need to be built with any Qt versions still present on a user's system. While having new Qt 4 applications nowadays is strange we still have lots of them to maintain (I can give figures/examples if needed). But again, I might be stretching it too much. Or not. > The other extreme are development tools that almost never need to be run > directly by directly the user, at all. That's the case for rcc, uic, moc, > lupdate, lrelease, qmlcachegen, etc. Those should not be in the $bindir in > the first place: they should live in $libexecdir and ought to be found by > way of the .cmake and .pc files, as in: > pkg-config --variable=libexecdir Qt6Core Exactly. > That only leaves front-end tools that are intricately tied to the Qt version > that need renaming. The only two I can think of that fits this description > are the "qml" and "qmlscene" pair. If we're feeling nice, we can do it too > for diagnostic tools, like qtdiag, qtpaths, qtplugininfo. It would probably be the safest thing to do. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
