> -----Original Message----- > From: development-bounces+maurice.kalinowski=digia....@qt-project.org > [mailto:development-bounces+maurice.kalinowski=digia....@qt-project.org] > On Behalf Of Thiago Macieira > Sent: Freitag, 19. Oktober 2012 02:38 > To: development@qt-project.org > Subject: Re: [Development] Summary of renaming changes > > On sexta-feira, 19 de outubro de 2012 10.17.39, Lincoln Ramsay wrote: > > On 19/10/12 01:30, Thiago Macieira wrote: > > > After all of my patches are integrated, here are the changes that > > > will > > > happen: > > > > > > - bin: > > > > > The following tools have been renamed: > > So... You just don't care about the calls from myself and others to > > leave the names alone instead install newly-named (aliased) things > > into common directories (ie. /usr/bin) as is standard practice for > > other things that get co-installed? > > I'm not ignoring. I was just summarising the effort I've done so far. I'm > posting it > so we can review it and correct further, if needed. > > > eg. > > > > /usr/bin <-- something special has to be done here, (eg. qmake-qt5 or > > qmake as a symlink to a specific Qt install) /usr/lib/qt5/bin <-- > > binaries go here with their NORMAL names > > Thanks, but I don't think that solves many problems. That extra path would > exist > only for people like you or I who are used to them. I don't see further use > for > them. Here's why: > > External tooling will need to deal with the new names. For example, a > buildsystem needs to search for qmake5 or qmake-qt5. And it needs to find > qmake so that it can query where the other binaries are located, as they > could be > in: > /usr/lib/qt5/bin > /usr/lib64/qt5/bin > /usr/lib/i386-linux-gnu/qt5/bin > /usr/local/lib/qt5/bin > /home/thiago/obj/qt/qt5/qtbase/lib/qt5/bin > and so forth > > The tool cannot depend on the legacy path being on $PATH or that, if it is on > $PATH, that the Qt 5 path comes before the Qt 4 one. Besides, we as helpgivers > cannot depend on that either when giving advice: we need to tell people to run > "qmake5". > > What's more, this creates more work for us (well, for me, since I'm the one > doing > this). Adding symlinks in either direction is very hard, especially since > they don't > work on Windows. The tool would need to be copied instead[1].
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. 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? Maurice > > I did propose that we move all binaries except qmake and the end-user > applications to a "libexec" dir, which is basically what that dir of yours is. > It didn't happen because, as I was starting this effort, I was convinced to > go for > the option of renaming everything instead: moc, uic, rcc, etc. are well- > defined > tools with well-defined interfaces, manuals, etc.. They are not internal > helpers. > > [1] we already copy the .dll files because of that problem and the DLLs are > much > larger, so copying the executables is no big deal. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
