[Development] New proposal for the tool naming

[Oswald Buddenhagen]

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.

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

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

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.

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.

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

we don't even need to specify a real registry of qt versions:
we may define only the (pretty minimal) interface of qset and leave the
implementation up to distributors. their implementations can deduce the
available versions by looking at the file system (which follows the
particular distributor's policy).
of course that would leave out user-compiled versions. that's only
relevant if we want to make it *the* qt version registry also used by qt
creator - i suspect most users wouldn't mind too much if the distro tool
wouldn't know about their private versions.

anyway, the bottom line is: this is an entirely separate tool/-set, and
qt should stay unmodified.