Hi! On Tue, 16 Feb 2021 at 11:37, Ville Voutilainen <[email protected]> wrote: > > On Tue, 16 Feb 2021 at 15:35, Kai Köhne <[email protected]> wrote: > > And again, this is not something limited to Qt. Last time I checked, the > > executable to run Python 3 on Windows is python.exe, not python3.exe. On > > Debian at least it's python3. This hasn't blocked Python from being > > perceived as overall beginner friendly ... > > Uh.. that seems like an apples-and-oranges comparison. On linux, it's > expected and conventional that if you install both > python 3 and python 2, both are available in the usual PATH, neither > eclipses the other, and you can cd between python 2 > and python 3 projects and run both, without switching environments or > alternatives in between.
Exactly, and that's because you have both python2 and python3 executables on path. > On windows, I don't know what's conventional. In many cases, a > shortcut is used that launches a command prompt > with the right environment, and using two versions in the same command > prompt just isn't done. And again, exactly. So comparing against Python on Windows is, as you say, and apples-and-oranges comparison. > > So, I would stick to qmake as canonical name, also in the documentation. We > > can mention that it's sometimes called qmake6 on Linux. But forcing > > everyone to change their habit and scripts just for the sake of consistency > > with a fraction of the users that use a global installation on Linux, and > > do not use update-alternatives, is IMO not a good move. > > update-alternatives is a long-term system-wide configuration change. > Changing PATH is a shorter-term user-specific one. That's how I switch > between compilers, and I wouldn't dream of using update-alternatives > to switch between them. Especially not > on multi-user systems, where it's none of my business to change the > alternative used for a system compiler > for other people. I *can't* do an update-alternatives on a build > server, and I *shouldn't*. That doesn't mean that > a build server installation couldn't have both qt 5 and qt 6 installed > in a system-wide location. > > Switching between qt 5 and qt 6 via update-alternatives is Just Wrong. > If our approach requires it, our approach > is broken. And in fact we can use python (again) as a good example: let the user-facing binaries have the major version in them. And this time the comparison is on Linux, where it belongs. Kai: we the maintainers have been asking for the right solution since the Qt3 to Qt4 switch. For a developer having to add the "6" after the tool, while it might be a change, it will pretty sure be straightforward. And by doing this we fix the issue not only for this release but for every major release here upon. Tip: many Linux users expect qmake6 or some other variant to call qmake. Now it's time to make it official *and* consistent for everyone. _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
