[Development] Summary of renaming changes

[Thiago Macieira]

On sexta-feira, 19 de outubro de 2012 08.52.47, Ziller Eike wrote:
> > External tooling will need to deal with the new names.
> 
> I don't see why.
> It's possible to ask qmake for the path where the other binaries, headers,
> examples, and a lot of other stuff are supposed to be: "qmake -query". If
> we set the standards for distributions to have also e.g.
> /usr/lib/qt5/bin/qmake

Yes, you can query qmake. But first you need to find it. Currently and for the 
next couple of years, that qmake is definitely not Qt 5's. It might be Qt 3's 
or Qt 4's, but will definitely not be Qt 5's.

> in addition to a symbolic link from /usr/bin/qmake to the "current" setting,
> a script can take "qmake" from the PATH (which can be set to whatever), and
> ask it where the other things are.

A system-wide symlink is not a solution for people who aren't admins. Besides, 
that breaks multiple builds, for people who will be engaged in porting and 
need to try the older Qt 4 application at the same time as the newer Qt 5 one.

The only solution that works is modifying PATH, with a script (it can't be 
done globally either, for the same reasons as above).

> > I did propose that we move all binaries except qmake
> 
> Why leave qmake out of the equation?

See above. You need to find qmake in order to find the other tools. And "qmake" 
will not be Qt 5's.

Therefore, we need another name for the tool that lets us find the other tools. 

Here's an idea: put *all* tools in libexec, including qmake, but install a 
new, global qt5-config. That tool allows one to find the rest, like:

	kde4-config --prefix
	python3 --prefix
	icu-config --prefix
	xslt-config --prefix
	mysql_config --prefix

Or the other 47 that I have in my system:
$ ls /bin/*[_-]config | wc -l
52

Note: such tool needs to work for multiarch too, unlike mysql_config.

> > and the end-user
> > applications to a "libexec" dir, which is basically what that dir of yours
> > is. It didn't happen because, as I was starting this effort, I was
> > convinced to go for the option of renaming everything instead: moc, uic,
> > rcc, etc.  are well- defined tools with well-defined interfaces, manuals,
> > etc.. They are not internal helpers.
> > 
> > [1] we already copy the .dll files because of that problem and the DLLs
> > are
> > much larger, so copying the executables is no big deal.
-- 
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/20121019/432b2311/attachment.sig>