[Development] New proposal for the tool naming

[Thiago Macieira]

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 
buckets:

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 
example.

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>