Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
On 2018 M12 16, Sun 14:34:44 CET Thiago Macieira wrote: > On Sunday, 16 December 2018 13:47:36 PST Alexander Neundorf wrote: > > I also don't mind having moc6 etc. directly in bin/, instead of being > > hidden in libexec. Well, I actually prefer if they are in bin/, because > > there they are easy to find an run, and sometimes that's necessary during > > development. For anything in libexec I always forget where it is and have > > to search it again once I need it. > > How many times have you had to run moc, uic or rcc manually? I didn't count ;-), but more than once. Usually for debugging buildsystem-related issues... Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
On Sunday, 16 December 2018 13:47:36 PST Alexander Neundorf wrote: > I also don't mind having moc6 etc. directly in bin/, instead of being hidden > in libexec. Well, I actually prefer if they are in bin/, because there they > are easy to find an run, and sometimes that's necessary during development. > For anything in libexec I always forget where it is and have to search it > again once I need it. How many times have you had to run moc, uic or rcc manually? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
On 2018 M11 14, Wed 03:43:03 CET Kevin Kofler wrote: > Thiago Macieira wrote: > > But I've just remembered that Designer loads plugins and those are quite > > clearly tied to the Qt version. The file format is backwards compatible > > and has remained so for a few years. It is possible that the plugins > > generate the same XML regardless of version, but I think we shouldn't risk > > it. So yes, Designer should be versioned. > > I think it would be much safer to just version everything. +1 I also don't mind having moc6 etc. directly in bin/, instead of being hidden in libexec. Well, I actually prefer if they are in bin/, because there they are easy to find an run, and sometimes that's necessary during development. For anything in libexec I always forget where it is and have to search it again once I need it. Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
On Monday, 19 November 2018 11:42:48 PST Lisandro Damián Nicanor Pérez Meyer wrote: > b) If at some point we can agree it has been decided, is there any way I > could start contributing code in order to achieve this? Maybe I should just > wait until the new build system is on stage? something else? Since it's a Qt 6 thing, it should happen with the buildsystem, which means we need to actually decide on which one to use. Even though it currently looks there's only one in contention, it's not a *decision*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
El martes, 13 de noviembre de 2018 23:58:28 -03 Thiago Macieira escribió: > On Tuesday, 13 November 2018 18:43:03 PST Kevin Kofler wrote: [snip] > > I think it would be much safer to just version everything. > > > > Just remember Assistant in Qt 4, where early 4.x releases shipped an > > Assistant that was essentially compatible with the Qt 3 version, but it > > was > > later renamed to assistant_adp (and later dropped from the Qt distribution > > and shipped as an unmaintained separate legacy tarball) and a new > > incompatible Assistant (the QCH one) was introduced. > > Ok, so two categories only: > 1) applications run by the user (in bin, versioned) > 2) applications run only during build (in libexec, unversioned) I would of course agree here. But so far only three of us participated in this thread, so I would like to ask: a) Is there something else I could do to make this a consensus decision? Or maybe do something to make this the roadmap for Qt 6? b) If at some point we can agree it has been decided, is there any way I could start contributing code in order to achieve this? Maybe I should just wait until the new build system is on stage? something else? Cheers, Lisandro. -- When the winds of change are blowing, some people are building shelters, and others are building windmills. Old Chinese Proverb 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
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
On Tuesday, 13 November 2018 18:43:03 PST Kevin Kofler wrote: > Thiago Macieira wrote: > > But I've just remembered that Designer loads plugins and those are quite > > clearly tied to the Qt version. The file format is backwards compatible > > and has remained so for a few years. It is possible that the plugins > > generate the same XML regardless of version, but I think we shouldn't risk > > it. So yes, Designer should be versioned. > > I think it would be much safer to just version everything. > > Just remember Assistant in Qt 4, where early 4.x releases shipped an > Assistant that was essentially compatible with the Qt 3 version, but it was > later renamed to assistant_adp (and later dropped from the Qt distribution > and shipped as an unmaintained separate legacy tarball) and a new > incompatible Assistant (the QCH one) was introduced. Ok, so two categories only: 1) applications run by the user (in bin, versioned) 2) applications run only during build (in libexec, unversioned) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
Thiago Macieira wrote: > But I've just remembered that Designer loads plugins and those are quite > clearly tied to the Qt version. The file format is backwards compatible > and has remained so for a few years. It is possible that the plugins > generate the same XML regardless of version, but I think we shouldn't risk > it. So yes, Designer should be versioned. I think it would be much safer to just version everything. Just remember Assistant in Qt 4, where early 4.x releases shipped an Assistant that was essentially compatible with the Qt 3 version, but it was later renamed to assistant_adp (and later dropped from the Qt distribution and shipped as an unmaintained separate legacy tarball) and a new incompatible Assistant (the QCH one) was introduced. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
On Tuesday, 13 November 2018 15:19:58 PST Lisandro Damián Nicanor Pérez Meyer wrote: > 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? Yes. Assistant, Linguist, the D-Bus tools should be. But I've just remembered that Designer loads plugins and those are quite clearly tied to the Qt version. The file format is backwards compatible and has remained so for a few years. It is possible that the plugins generate the same XML regardless of version, but I think we shouldn't risk it. So yes, Designer should be versioned. > > 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
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
Re: [Development] Qt6/Qt5 coinstallability (Linux distributions)
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. 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 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. And then there's qmake. I'd really love if it were a backwards-compatible tool that worked for both Qt 5 and 6. It's unlikely to happen, since choosing the Qt version has always been done by selecting the proper qmake. So I imagine it will be one of the renamed ones. $ ls -1 `qmake -qt5-installed -query QT_INSTALL_BINS` assistant canbusutil designer fixqt4headers.pl lconvert linguist lrelease lupdate moc pixeltool qdbus qdbuscpp2xml qdbusviewer qdbusxml2cpp qdistancefieldgenerator qdoc qgltf qhelpgenerator qlalr qmake qml qmlcachegen qmleasing qmlimportscanner qmljs qmllint qmlmin qmlplugindump qmlpreview qmlprofiler qmlscene qmltestrunner qscxmlc qtattributionsscanner qtcreator qtcreator.sh qtdiag qtpaths qtplugininfo qtwaylandscanner qvkgen rcc repc sdpscanner syncqt.pl uic xmlpatterns xmlpatternsvalidator -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
