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.
> The proposal: > > 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. > 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). 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. 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. 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++. we don't even need to specify a real registry of qt versions: we may define only the (pretty minimal) interface of qset and leave the implementation up to distributors. their implementations can deduce the available versions by looking at the file system (which follows the particular distributor's policy). of course that would leave out user-compiled versions. that's only relevant if we want to make it *the* qt version registry also used by qt creator - i suspect most users wouldn't mind too much if the distro tool wouldn't know about their private versions. anyway, the bottom line is: this is an entirely separate tool/-set, and qt should stay unmodified. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
