[Development] Summary of renaming changes

[Thiago Macieira]

On sexta-feira, 19 de outubro de 2012 10.17.39, Lincoln Ramsay wrote:
> On 19/10/12 01:30, Thiago Macieira wrote:
> > After all of my patches are integrated, here are the changes that will
> > happen:
> > 
> > - bin:
> 
> > The following tools have been renamed:
> So... You just don't care about the calls from myself and others to
> leave the names alone instead install newly-named (aliased) things into
> common directories (ie. /usr/bin) as is standard practice for other
> things that get co-installed?

I'm not ignoring. I was just summarising the effort I've done so far. I'm 
posting it so we can review it and correct further, if needed.

> eg.
> 
> /usr/bin <-- something special has to be done here, (eg. qmake-qt5 or
> qmake as a symlink to a specific Qt install)
> /usr/lib/qt5/bin <-- binaries go here with their NORMAL names

Thanks, but I don't think that solves many problems. That extra path would 
exist only for people like you or I who are used to them. I don't see further 
use for them. Here's why:

External tooling will need to deal with the new names. For example, a 
buildsystem needs to search for qmake5 or qmake-qt5. And it needs to find qmake 
so that it can query where the other binaries are located, as they could be 
in:
	/usr/lib/qt5/bin
	/usr/lib64/qt5/bin
	/usr/lib/i386-linux-gnu/qt5/bin
	/usr/local/lib/qt5/bin
	/home/thiago/obj/qt/qt5/qtbase/lib/qt5/bin
	and so forth

The tool cannot depend on the legacy path being on $PATH or that, if it is on 
$PATH, that the Qt 5 path comes before the Qt 4 one. Besides, we as helpgivers 
cannot depend on that either when giving advice: we need to tell people to run 
"qmake5".

What's more, this creates more work for us (well, for me, since I'm the one 
doing this). Adding symlinks in either direction is very hard, especially 
since they don't work on Windows. The tool would need to be copied instead[1].

I did propose that we move all binaries except qmake 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/20121018/458d16a0/attachment.sig>