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

[snip]

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

[snip]

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.

Andy
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to