On 18 Nov 2020, at 00:41, Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com<mailto:perezme...@gmail.com>> wrote:
On Tue, 17 Nov 2020 at 14:09, Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: On Tuesday, 27 October 2020 09:34:44 PST Thiago Macieira wrote: Have we fixed it? I do not plan on updating qtchooser for Qt 6. Qt 6 should not install any binary with the same name as Qt 5 did. Lars and I just had a quick discussion on IRC about this and here's what we propose. Ground rules and caveats: 1) MOST tools do not need to be in $PATH for most users. We developers are not most users. For us, setting PATH is acceptable. We're also likely the only audience to have more than one 5.x or 6.x Qt version installed. 2) This recommendation need not be supported by the buildsystem in time for 6.0.0, but needs to be as early as possible and by 6.1 at the latest. This recommendation allows Linux distributions to apply workarounds meanwhile, other buildsystems to adjust (read: Meson), and for us to write docs and QUIP. 3) there's a question of cross-compilation relating to qmake and host tools, which I have not followed and do not understand the current state of. Need input here. With that in mind, our recommendation is as follows: a) ALL tools be installed to a binary directory that is not $prefix/bin b) SOME tools be symlinked/hardlinked/stubbed into $prefix/bin, with a suffix (we recommend a simple "6" instead of "-qt6") c) ADDITIONALLY, some further tools can be present unsuffixed Thinking a bit more about this, I wonder how many applications _really_ need a version. To start with, I think it’s important to recognise a difference between developer oriented tools and tools targeting end users. Most of our developer oriented tools are (or can be) dependent on the exact version of Qt installed. Thus the problem is larger than just a Qt 5 vs Qt 6 thing. Those tools should just stay in a version specific directory and should IMO not be exposed in the generic path for end users (moc should for example never end up in /usr/bin). Instead the correct version is found by the build system and called from there. And developers needing direct access to them should adjust their path to include those tools. For most end user facing tools, I wonder whether we actually need to support co-installation. The examples listed just below (linguist etc.) are backwards compatible, and it should be ok to simply install the latest version, similar to what is done with qtcreator. Once we have that, the question is what is left that actually has to have a versioned name? The question is what tools are those in lists (b) and (c). Starting with the easiest (c): - linguist - qdbus - qdbusviewer Those are user-facing tools that definitely do not depend on Qt version. It's up to the implementer to decide which Qt version they want these tools to be and any choice is fine. My guess is that for two of the three, it will depend mostly on Look-and-Feel with the desktop. But since these are an implementer's choice, Qt installation never installs those tools with the unsuffixed names by default. Agreed to all above. Then there's the question of which tools we recommend be in $PATH with a suffix (list (b)). Please expand on this list if necessary, with a reason. Here's the minimum list: qmake6 entry point for building qmake-based applications, situation similar to /usr/bin/python (see [1]) I am not yet 100% convinced it is. This is a build tool after all, and even changes with minor versions of Qt. I know Linux distributions do only ship one minor version, but many of our users have to manage multiple minor versions of Qt as well. And renaming qmake with every minor version is a no-go. qml6 I don't understand why, but I'm told it's necessary It’s a runtime for running qml files without a C++ entry point. But we can actually decide that this is a developer oriented tool and not have it linked into /usr/bin. qtdiag6 entry point for debugging problems with Qt 6 qtpaths6 because knowing the path in order to run the tool to get paths sounds weird. Having this in $PATH allows us to help users get to the other, debugging tools (qtplugininfo, qmlplugindump, etc.) Possibly also: assistant6 for reading Qt 6 help files when not using Qt Creator designer6 for those not using Qt Creator and needing to use Qt 6 plugins Offtopic, but I wonder how much those standalone apps are still being used today. Also agreed. I would consider assistant6 and designer6 to be included in list (b) due to past experience. Tools I don't know if they should or shouldn't be in this list: - pixeltool: it's a screen magnifier, never used it before, but clearly not something used at build time. Sounds like a user-facing app for me. - qtplugininfo: I sincerely don't know how it's being used. - qtwaylandscanner: same as above. - tracegen: same as above - sdpscanner: "Performs an SDP scan on remote device, using the SDP server represented by the local Bluetooth device." Sounds like a user-facing app. All of those are developer facing tools and shouldn’t be in /usr/bin at all IMO. Cheers, Lars -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ _______________________________________________ Development mailing list Development@qt-project.org<mailto: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