Thiago Macieira wrote: > To be clear: the reason people didn't want the renamed qmake was exactly > because people had build scripts and didn't want to update them, as Qt 5 > is mostly source compatible with Qt 4.
In practice, applications typically support only one or the other, only some libraries try to support both in one code base (in order to support applications using different Qt versions). Very few applications try to support both versions, and several that used to have already dropped Qt 4 support (see e.g. SDDM). And even for some libraries, their upstream preferred to release separate tarballs for the Qt 4 and Qt 5 versions. So in practice, client programs really want one specific version of Qt, so letting this be a decision of the user building the client program is inherently flawed. (It only leads to the program failing to build if the user selects the wrong Qt.) Our goal in Fedora has always been to make building programs just work (as soon as the required -devel packages are installed), without having to make configuration specific to the package being built. The suffixed binaries provide that (assuming that the program's build system looks for them, which is usually the case in practice due to distros having shipped Qt like that for years). As for the programs supporting both versions of Qt, as I explained in the other mails, in practice, those programs' build systems typically use a configure flag (e.g., the -D switches to CMake) to select the Qt version. Since this is a per-program decision (e.g., for a library, you want to build it with the correct version of Qt for the application you need the library for, or simply for both versions of Qt successively – and yes, the library ought to use different sonames depending on the Qt version it's built for! We also got many libraries fixed for that), the program's build system is the right place to make the selection, a user-account-wide configuration file is not. Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development