[Development] New proposal for the tool naming

[Oswald Buddenhagen]

On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
> 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.
> 
the bottom line being "nobody cares". hey, wait, why change anything
at all then? ;)
anyway, the actual argument against doing it is that if we don't do the
invasive tool renaming, the library renaming is pointless (because it
doesn't help). and if we do something similar to the current proposal
... the renaming is pointless (because the inc+lib paths can be found
with qmake).

> > 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.
> 
so ... given that one of the cases is broken anyway and needs *some*
fix, what's the use of complicating the layout in an attempt to decouple
the case that needs no fixing anyway? :}

> > > 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.
> 
that asymmetry is ugly. that tool should be named just "qt" (or
similar) and *all* actual qt binaries should be reachable only via the
option or symlink.

> > 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?
> 
i meant a "qt" tool without the "symlink trick". you totally don't want
to update all documentation to say "qt qmake", etc., and as a user i
positively don't want to type that.

> > 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.
> 
we don't actually need bootstrapping, only static linking.
anyway, using qt may be advisable if we use a config file based registry.
that's one of the reasons why i suggested that maybe we shouldn't.
but then, ini file and registry access (if even wanted) are pretty
trivial to write in plain c (look at kdm's inifile.c ...).

> Qt will need to be modified so that the *applications* like qdbus, qdbusviewer, 
> designer, assistant and linguist know where /usr/bin is.
> 
why should the apps need to know that?
also, it's a non-question when all executables live in one directory.