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' _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development