[Development] New proposal for the tool naming

[Konstantin Ritt]

>> > Why not use a tool of a new name? Why overload the meaning and
>> > responsiblity of qmake?
> <snip>
> If the new tool is to be installed to /usr/bin/qmake and the Qt 4 qmake is
> today at /usr/bin/qmake, packagers have to change everything in their Qt 4
> packages or they will conflict and not be coinstallable. I thought that was
> the main reason for this whole thing. If you covered that in your initial
> email, I missed it.

The packagers have to change the only Qt4 qmake's name/path and
register the existing installation(s) to be known to that new qmake
wrapper, nothing more.

>> > The easiest way to achieve that is probably to create a solution based on
>> > files and you create a ~/.config/qconfig-maemo5 which shadows the one in
>> > /etc/qconfig-maemo5 and adds what you want. (Assuming the -add-qt option
>> > described below would be implemented to find files like that, but you get
>> > the idea).
> <snip>
> Just to review who *is* supposed to benefit from this:
> * Not Windows or Mac users. They are already managed by the user

Qt users on Widnows could use such qmake to manage their Qt
installations. Have no clue about the Mac users, though.
My proposition was to not install this new qmake wrapper by default
iff libexecdir equals to bindir - so the old behavior could be
achieved easily.

> * Not SDK users on Linux
> * Not people who download binary libraries from qt-project
> * Not people who compile (and therefore choose the prefix of) their own Qt

An arbitrary Qt installation/build can be registered (just like Kits
in Creator).

> * Yes - people who use distro -dev(el)? packages to develop against Qt.
> * Yes - people who do user support on #qt, interest@, forums etc.
> * Newbies finding 3rd party documentation with consistent tool names.

Konstantin