[Development] New proposal for the tool naming

[Thiago Macieira]

On segunda-feira, 22 de outubro de 2012 19.23.23, Oswald Buddenhagen wrote:
> > > 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? ;)

Because of the portion of the 99% that *does* use qmake and needs to find it.

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

Except if you want the .so files in /usr/lib co-installable with the Qt 4 ones. 
Yeah, we could put them in /usr/lib/qt5/lib, but that sounds rather convoluted 
to me. It also introduces multiarch issues, since then we need one qmake per 
arch, instead of the solution we have now.

I want the Qt prefix to be /usr, not /usr/lib/qt5.

> > 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? :}

Exactly. That case that is broken needs attention and its solution is separate 
from this discussion.

I can't fix what's *already* broken due to the Qt 3 and Qt 4 mess. I can only 
fix going *forward* for Qt 5.

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

That is acceptable too. I can call the tool anything and symlink qmake to it 
(except on Windows where it will be an actual copy).

Symlinking the other tools is optional and should not be the default. 
Buildsystems need to find the other tools in libexec via full path and not 
depend on $PATH.

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

I do want to update all the documentation to say "qmake -qt5".

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

True, but you're splitting hairs. The "static QtCore" library in the regular 
build is called "libbootstrap.a".

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

I was planning on simple multiple-file reading. One file per Qt version it 
knows. It's a lot simpler and more package-friendly.

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

Rephrasing:

qdbus.pro needs to know where to put its output. Since it's not 
$$[QT_INSTALL_BINS], we need another path. But you're right that we don't need 
the change to QLibraryInfo. If anyone ever needs to find and run those tools 
(not counting their unit tests), QProcess is enough since it will search 
$PATH.

-- 
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/5a043524/attachment.sig>