[Development] Alternative Proposal (was: Re: Summary of renaming changes)
simon.hausmann at digia.com
Fri Oct 19 13:24:37 CEST 2012
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
(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
[See footnote  regarding the implementation of this solution]
(b) We can pre-/postfix the binary names and leave them in their default
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
Distros would configure Qt with -prefix /usr -bindir /usr/lib/qt5/libexec etc.
This could also be implemented via a convenience ./configure -fhs-compliant
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.
More information about the Development