[Development] Alternative Proposal (was: Re: Summary of renaming changes)

[Simon Hausmann]

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.