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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development