On Friday, October 19, 2012 04:16:14 PM Thiago Macieira wrote:
> Starting a new thread with some ideas based on the outcomes of the
> discussion. Many thanks to rittk, Simon, Lars and André who helped come up
> with this.
(and Tor Arne!)
> 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.
In all fairness, I think Ossi still disagrees here.
I personally agree though and I'm very glad to see that we're progressing
nicely in this rather tough topic :)
> 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.
>
> This directory is *not* expected to be in $PATH on any system and therefore
> the documentation cannot assume it is.
>
> In this directory, we'll install the tools not usually run by the user,
> tools that are often run by other tools. They will keep their current
> names. These tools are:
> qmake
> moc
> rcc
> uic
> qdbusxml2cpp
> qdbuscpp2xml
> lconvert
> lrelease
> lupdate
> qml*
> qhelpgenerator
> qhelpconverter
> qcollectiongenerator
> qdoc
>
> 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. Those applications are:
> qdbus
> qdbusviewer
> designer
> assistant
> linguist
> qglinfo
> pixeltool
> [creator]
>
> I'm open to suggestions on whether some of the tools should be symlinked
> here (e.g., qmlscene5 -> $libexecdir/qmlscene).
I like (1) and (2).
> 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:
>
> a) under most circumstances, it will simply find another qmake and pass
> through all arguments. That is:
> qmake -project
> basically will exec
> $someotherpath/qmake -project
>
> b) additionally, it accepts an extra argument (-select), which causes it to
> select a different Qt version. For example:
> qmake -qt=5 -project
> qmake -qt=4.8.4 CONFIG+=debug
> etc.
> As a shorthand, the option "-qtX" means "-qt=X".
> This argument will be stripped from the command-line before calling the
> real qmake.
> Without this option, it will fall back to a well-known environment variable
> (say, QT_SELECT=5). And if that is also missing, it selects some
> system-defined or user-defined default.
>
> c) it adds one extra option: -print-versions, which will list which Qt
> versions are known to this tool
>
> It is our intention that this new tool replace all pre-existing qmake found
> in $PATH. One tool to rule them all. Creator can query this tool to find
> all known Qt versions and populate its listing.
Sounds like a good idea to turn things around the way you suggest, that Qt
Creator queries this tool instead of the tool using Qt Creator's database.
Qt Creator could perhaps even being migrating over to that db.
> In turn, the official Qt 5 documentation should always talk about qmake
> like so:
> qmake -qt5 "LIBS+=-L/usr/local/lib -lmysqlclient_r" mysql.pro
>
> This allows the Troll qset function to be implemented like:
> function qset() {
> local prefix=$(qmake -qt=$1 -query QT_INSTALL_PREFIX)
> if [ $? -gt 0 ]; then
> echo >&2 No such Qt version "$1"
> else
> export QT_SELECT=$1
> export QTDIR=$prefix
> local libdir=$(qmake -query QT_INSTALL_LIBS)
> export
> LD_LIBRARY_PATH=$libdir${LD_LIBRARY_PATH+:$LD_LIBRARY_PATH)
> export PKG_CONFIG_PATH=$libdir/pkgconfig:$PKG_CONFIG_PATH
> # optional:
> #PATH=$(qmake -query QT_INSTALL_BINS):$PATH
> fi
> }
> function qcd() { cd $QTDIR; }
>
> Additionally, this tool may support options like -add-qt and
> -set-default-qt. I'm also open to adding an option -run-tool= (e.g., qmake
> -qt=5 -run- tool=qmlplugindump) if that's of interest to people.
It would be lovely it it supported registration, because then the postinst
scripts of distro qt packages could call it to _register_ Qt versions.
> I haven't decided whether this tool should be a shell script, a perl script
> or another bootstrapped executable.
I'm inclined to suggest a bootstrapped executable. If it had a shell sourcing
mode like dbus-launch, then a separate qset program can be implemented as a
batch file on Windows (that can set environment variables) or as a shell
function on Unixy platforms.
Simon
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
