[Development] Summary of renaming changes

[Poenitz Andre]

Thiago Macieira:
> On sexta-feira, 19 de outubro de 2012 06.07.34, Kalinowski Maurice wrote:
> > On Windows there is no global qmake or such to call and distinguish between
> > versions. Each Qt version will have to live in its own package, either made
> > by the binary distribution or self-compiled. Hence that argument is
> > obsolete.
> 
> For Windows, that's correct.
> 
> > So you are creating distribution scripts which then point to the currently
> > used Qt version for qmake? If not, who is creating those for the other
> > libraries/tools, which follow a similar attempt of having a simlink in
> > /usr/bin or /usr/local/bin pointing to libexec. Has anyone talked to those
> > package managers how they see it?
> 
> No, we're not creating scripts. As I replied to Lorn, I don't see the value in
> having qmake duplicated in $bindir and $libexecdir.
> 
> Since $bindir/qmake is already taken, if we put something in $bindir, it needs
> to be called something else. The only other option is to not install anything
> in $bindir. If we choose that, however, how will users find qmake in the first
> place?
> 
> So we have $bindir/qmake5 and we update all the documentation to say "qmake5".
> What's the use of $libexecdir/qmake now?
> 
> In my plan, "qmake" will never be for Qt 5. Whether it's for Qt 3 or for Qt 4,
> it's undefined. That mess is already present and we can't fix it anymore.

I started -2'ing the changes, based on the outcome of a cost/benefit "analysis":

- The "problem" only exists on Linux 
   * There are existing, working solutions to the "problem" there
   * There are skilled people (distro packagers) there perfectly 
      capable of handling the "problem" 
   * The majority of Qt users is not affected at all.

- The "solution" is invasive.
   * Some of the follow-up changes are only triggered by the renaming
     E.g. the "need" to co-install lupdate does not exist yet, but is 
     _introduced_ by the qmake changes.
   * It affects any user project setup involving moc, uic, etc "custom
     buildstep", like the ones _all_ Qt using Visual Studio projects have,
     therefore eliminating the possibilty of having a code base running
     on both Qt 4 and Qt 5, and even hampering a direct Qt 4 -> Qt 5 port.
  * Documentation needs to be adjusted.
  * Existing third party documentation of Qt in use, howto's, tutorials, 
    in the *net lose value, because it will be not accurate anymore.

This is a completely unreasonable trade-off.

Andre'







Andre'