[Development] New proposal for the tool naming

Thiago Macieira thiago.macieira at intel.com
Mon Oct 22 18:08:38 CEST 2012

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 

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 

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121022/441facbc/attachment.sig>

More information about the Development mailing list