On 19 Oct 2012, at 02:37, Thiago Macieira <[email protected]> wrote:
> 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. I don't see why. It's possible to ask qmake for the path where the other binaries, headers, examples, and a lot of other stuff are supposed to be: "qmake -query". If we set the standards for distributions to have also e.g. /usr/lib/qt5/bin/qmake in addition to a symbolic link from /usr/bin/qmake to the "current" setting, a script can take "qmake" from the PATH (which can be set to whatever), and ask it where the other things are. > 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]. > > I did propose that we move all binaries except qmake Why leave qmake out of the equation? > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
