[Development] Summary of renaming changes

Shaw Andy Andy.Shaw at digia.com
Fri Oct 19 10:03:39 CEST 2012

> looks like there's quite some discussion about Thiago's proposal. Let's see if
> we can get at least agreement on most of the changes and then focus on the
> parts that are controversial.
> Going through the list below, most of the changes will not affect anybody in a
> big way.
> On Oct 18, 2012, at 5:30 PM, Thiago Macieira <thiago.macieira at intel.com>
> wrote:
> > After all of my patches are integrated, here are the changes that will
> happen:
> >
> > - bin:
> > The following tools have been renamed:
> > 	qmake	-> qmake5
> This one is visible to the developer.

This is the one that's going to be hard for people to swallow the most especially on Windows as there the whole setup is straightforward as you just ensure you have the one version of Qt in your path and thus it will point to the right one.  I've been doing this for a long time as do a number of people I have communicated with in the past even within the Qt 4.x range because one version of qmake is strictly speaking not compatible with the other even from 4.8.1 to 4.8.2 because it has hard-coded paths in it.  So you could still end up picking up the wrong version anyway and subsequently end up compiling and linking against the wrong version of Qt but generally at that level it is not a big problem at least.

Is there no way we could compromise on this?  For instance by adding a symlink or something like that so that if someone types qmake it will invoke qmake5, that way if the distributors don't want that they can just remove it and then everyone is happy, the docs would refer to qmake5 and there is a solution there to help people transition over.  Granted I know that people could just add this themselves, but I get the feeling that I will be hearing a lot about this otherwise.


> > 	lconvert	-> lconvert5
> > 	lrelease	-> lrelease5
> > 	lupdate	-> lupdate5
> These tools are in-between, as they IMO get called both by build systems as
> well as by developers directly. But if they are not compatible with Qt 4, we
> can't really have the same name unfortunately.

For these I have the same problem as I do with qmake because they are invoked by the user directly too and thus the same suggestion about having a symlink stands in this case for me too.


Maybe we should open this up for more feedback on a blog post perhaps?   A lot of the people would be using it aren't necessarily going to see the change here and therefore they may have some good comments on it.


More information about the Development mailing list