On Thursday, October 18, 2012 08:30:03 AM Thiago Macieira wrote: [...] Tor Arne and I have been discussing this once more and we'd like to make an alternative proposal. But first let's try to summarize.
(1) It seems that there is an agreement on the naming of the libraries and pkg-config files. (2) It also seems that there is an agreement that we don't have to rename the applications such as Qt Creator, Qt Designer, etc. - programs that are very much meant to be launched explicitly by the user via the menu. (3) This leaves us with the command line tools such as qmake, moc and uic where we have a conflict _only_ on Linux when they're installed by distributions in /usr/bin. On Mac OS X and Windows co-installation is an established concept for Qt users by containing each version in different directories and making a choice via the PATH environment variable. The same approach is used by users of Qt compiling from source on Linux as well. The only problem left is co-installation of Qt when it is supplied by the Linux distribution. Regardless of the solution we find for Qt distro packages, it seems sensible that the Qt users can continue to find a /usr/bin/qmake program that corresponds to the most recent release of Qt. This provides consistency with Qt on other platforms as well as the handling of other command line programs such as python, gcc, ruby, etc. within the distros. With this in mind, let's look at the possible options of namespacing the command line tools: (a) We can keep the names but contain them in a directory outside of /usr/bin, just like on Windows, Mac OS X and source builds. This would mean that /usr/bin/qmake is implemented as a symlink to for example /usr/lib/qt5/libexec/qmake. [See footnote [1] regarding the implementation of this solution] (b) We can pre-/postfix the binary names and leave them in their default location /usr/bin. This would mean that /usr/bin/qmake is implemented as a symlink to /usr/bin/qmake5. However for consistency this would mean that qmake would have to be renamed to qmake5 on the other platforms, too, where we don't have a problem to solve and the renaming just introduces unnecessary changes to existing workflows, as described by numerous people in this thread, such as having to change existing vcproj files or changes in Qt Creator to find the right qml viewer to launch. The first option however matches the other platforms and existing workflows and has no disadvantages compared to the pre-/postfixing of the binaries. In fact it has advantages, such as continuing to offer the ability to put the contained directory into your PATH, just like you do it for source builds and on the other platforms. In short: We find that there is no _need_ to rename the tools and that we can solve the problem of co-installation using versioned directories. Simon & Tor Arne [1] Implementation: Distros would configure Qt with -prefix /usr -bindir /usr/lib/qt5/libexec etc. This could also be implemented via a convenience ./configure -fhs-compliant parameter. We would then add an option to configure that ensures that at install time a symlink is created from /usr/bin/qmake<distro configured suffix> to the binary in libexec. This allows you to call a specific version of qmake conveniently from /usr/bin if required. The only missing part then is the missing symlink of /usr/bin/qmake to the real qmake binary, which is a distribution specific mechanism, such as update- alternatives on Debian based distros. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development