On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: > On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: > > Note: this applies to the *tools* only. The library naming and > > installation > > paths for plugins and QML files has remained uncontested so far, so we > > appear to have a consensus. > > only if you conveniently ignore my two (or three?) mails saying the exact > opposite. the problem with renaming the libraries is the same as with > tools: project files not based on qmake need to be adjusted.
Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. > > 1) we introduce a $libexecdir configuration option to qmake and > > QLibraryInfo. For backwards compatibility, this $libexecdir will receive > > the legacy names of QT_INSTALL_BINS and QLibraryInfo::BinariesPath. It > > will default to $prefix/libexec/qt5, which some distros will change to > > $prefix/lib/qt5/libexec. > > > > 2) the $bindir, defaulting to $prefix/bin, will now be found by qmake > > property QT_INSTALL_APPS and QLibraryInfo::ApplicationsPath. It contains > > end-user applications that retain backwards compatibility of purpose as > > well as output. > against. > all binaries should be in one directory as far as QLibraryInfo (and > thus qmake) is concerned. everything else will just again be a PITA for > non-distro users. > also, it's all documented tools. nothing libexec about it. but that's > just a name. I beg to differ. Let's take the example of a buildsystem that is trying to retain source compatibility (thus, we're excluding cmake and, for many things, qmake too [think of QT += widgets print-support]). We can group them in two buckets: A) those that run those tools without absolute paths B) those that run them with absolute paths How do they find the absolute path? The only answer is "qmake -query QT_INSTALL_BINS". Since my proposal keeps that compatibility, those buildsystems are not broken. This includes Creator's translation rules, for example. And I contend that the Bucket A is already broken without user intervention. For Bucket A to work, the user must set the PATH to point to where the tools are. Either the user does this manually and will adapt anyway to a new installation, or the user has a script that she will again adapt. Since adaptation is necessary, adding the libexec path to PATH is no big deal. Because if she doesn't, we run into the problem that /usr/bin/moc might be Qt 3's or Qt 4's. > > 3) In addition, we'll create a *new* tool also called qmake that will be > > > installed to $bindir. This tool shall have the following behaviours: > if you call it qmake, then you should wrap all other binaries as well (as > we have established, lupdate blurs the line, and the gui tools will be > renamed by some distros no matter how much you disagree with that). Easy to do with qmake -run-tool=lupdate and using argv[0] as a shorthand. > a separate tool which is used as a wrapper will not work - it's just > utterly cumbersome, and we cannot retroactively adjust the documentation > anyway. Why is it cumbersome? We don't need to retroactively adjust documentation anyway. The tools found in $PATH are Qt 4's (or Qt 3's, that mess already exists), since that's what's documented. We need only change the documentation for the future. > my favorite remains a PATH-manipulating qset, but that has the downside > that it needs to be executed at shell startup, which may be considered > invasive by some. Yes, and it needs to get the listing of which Qt are available from somewhere. That "somewhere" is this tool I'm proposing. > so we indeed arrive at a qset which controls wrappers for all qt > executables. and you need to make these wrappers *cheap* (plain c) - > invoking moc and uic is expensive enough, with their huge baggage of a > static qt and libstc++. I can do that, though I don't think they're THAT expensive. > anyway, the bottom line is: this is an entirely separate tool/-set, and > qt should stay unmodified. Yes and no: it's an entirely separate tool, except that it might need to be bootstrapped. That would require it live in qtbase.git. Qt will need to be modified so that the *applications* like qdbus, qdbusviewer, designer, assistant and linguist know where /usr/bin is. -- 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 [email protected] http://lists.qt-project.org/mailman/listinfo/development
