[Development] New proposal for the tool naming

Ziller Eike Eike.Ziller at digia.com
Mon Oct 22 12:59:58 CEST 2012


Fine with me, with a comment inline.

++ Eike

On 20 Oct 2012, at 01:16, Thiago Macieira <thiago.macieira at intel.com> 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.
> 
> 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.

That sounds like a good thing to have, yes.

> 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

Just as a side note, that requires that Windows and Mac to also have this tool, and e.g. on Windows to have that tool in the PATH and pointing to the corresponding Qt for the environment set up shell scripts. In the SDK, the tools/ directory might be a good place for it.

Another option would be to still just write "qmake foo.pro" in the documentation and document that one needs to make sure to use Qt5 when reading the Qt5 documentation… after all, on Windows and Mac, developers also manage to figure out how to call qmake.

> 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 at qt-project.org
> 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




More information about the Development mailing list