[Development] Summary of renaming changes

Thiago Macieira thiago.macieira at intel.com
Fri Oct 19 19:13:27 CEST 2012

On sexta-feira, 19 de outubro de 2012 08.47.08, Ziller Eike wrote:
> Another thing that comes to my mind, that will break when renaming tools,
> instead of installing links in paths like "/usr/bin" and keeping the the
> tools unrenamed in specific version directories:
> At the moment one can define an "external tool" in Qt Creator.
> Configuration of these external tools is in Environment > External Tools,
> you can define any executable to run there with arguments etc, and a menu
> item for the tool will be shown in Tools > External.
> E.g. we ship by default with an external tool definition for running lupdate
> and lrelease, and the "executable" we run is defined as:
> %{CurrentProject:QT_INSTALL_BINS}/lrelease
> Qt Creator resolves that variable in there by taking the current project,
> taking the current Qt version setting for that project, and asking that Qt
> version for "qmake -query QT_INSTALL_BINS".
> At the moment that should work for Qt4 and Qt5.
> If you rename lrelease to lrelease5 (or any other tool that we ship), this
> is no longer possible and gets pretty fancy.

Having lrelease unrenamed in a different path would still require a change in 
the definition, to %{CurrentProject:QT_INSTALL_LIBEXEC}/lrelease.

In any case, I think that lrelease and lupdate being run directly is the wrong 
solution. They should be run by the Makefile, by having a correct .prf that 
gets processed and adds the correct rules.

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/2b6895f4/attachment.sig>

More information about the Development mailing list