[Development] Summary of renaming changes

[Ziller Eike]

On 19 Oct 2012, at 02:37, Thiago Macieira <thiago.macieira at intel.com> wrote:

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

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

> 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

Why leave qmake out of the equation?

> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B