FWIW, +1 - with one modification - reflect at least the minor version in the install path - so $prefix/libexec/qt5.0, if not $prefix/libexec/qt5.0.0.
I think there is probably a simple rule we could maintain: Keeping the names of developer visible tools the same is, IHMO, a must. Tools that are not developer visible, but called through generated build environments (e.g. Makefiles generated by Qmake) can be changed. $0.02 Ben ----- Original Message ----- > From: Thiago Macieira <thiago.macie...@intel.com> > To: development@qt-project.org > Cc: > Sent: Friday, October 19, 2012 7:16 PM > Subject: [Development] New proposal for the tool naming > > 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. > > 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. > > 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). > > 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. > > 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. > > I haven't decided whether this tool should be a shell script, a perl script > or > another bootstrapped executable. > > Please comment. > > -- > 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 > _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development