On Wed, 18 Nov 2020 at 13:45, Thiago Macieira <[email protected]> wrote: > > On Wednesday, 18 November 2020 04:34:40 PST Lisandro Damián Nicanor Pérez > > > So basically: > > > > - Move out of $prefix/bin (and thus out of $PATH) every developer-oriented > > tool. > > - Ensure that user-facing applications will be backwards compatible > > with Qt 5 for all the Qt 6 timeline. > > I don't think that will work for qmake6 (see below). I am willing to accept > this for all other (developer) tools. > > As for user-facing, here's the litmus test: the application can be moved out > of the Qt repositories into one of its own. And then we do exactly that. > Preferably also removing the use of private API in the process.
That would be simply awesome. > We've long had the question about translators wanting to install Linguist, but > the only installation we have of it is the full Qt, which requires a compiler > to also be present. Instead, we should provide translators with an installable > Linguist using the Installer Framework for Windows, a macdeployqt bundle in a > .dmg for Macs and, if we're feeling adventurous, a FlatPak for Linux. > > > But then I wonder if designer shouldn't stay on $PATH or not. Because > > even if it's a developer tool it's one expected to be on $PATH much > > like Qt Creator. The developer tools that can stay out of $PATH are > > the ones that can be easily callable from within toolchains (qmake, > > cmake, etc). But then again we distros could simply make a > > $prefix/bin/designer6 symlink. Telling our users "just use designer6" > > it's really not a big deal, even if the docs just say "designer". > > That's not an option. The docs must say either: > a) "run designer6" > or > b) "run <QTDIR>/bin/designer" In that case I would prefer (a) because it's situation is almost the same as the qmake one you describe below. > > > 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. > > Well, that's the exact opposite reply I've got (from Ossi?) on Qt 5.0 > > times. qmake needed to be on path in order to be able to query it for > > some paths. But if that's no longer the case then yes, it can stay > > away. > > qmake6 needs to be on PATH because that's how we will tell people how to build > their applications. Telling users to go discover where their Linux > distributions installed Qt6 is not acceptable, in my point of view. Agreed, that's why I followed my initial mail comparing it to CMake, I've just realized it later. And I think a tool like designer should follow the same path. > In any case, since we *need* qtdiag6 and qtpaths6, I don't see what's the harm > in having qmake6 too. > > > > 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. > > Still a tool that is expected to be called by humans though. And then > > again we could easily keep a $prefix/bin/qml6 link. > > I don't care enough. I'm sure I haven't run this tool in 3 years. I even > thought "qmlscene" was the one we were supposed to run since 5.0... > > I'm just following what has been said in this thread that some people do run > it. > > > > All of those are developer facing tools and shouldn’t be in /usr/bin at > > > all IMO. > > And again, they could be easily symlinked with a prefix if needed. > > I'd like to come to a consensus so that every installation follows procedure > and is supported by docs. I'd rather Linux distributions didn't feel the need > to start adding more symlinks. Right. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
