[Development] New proposal for the tool naming

Thiago Macieira thiago.macieira at intel.com
Tue Oct 23 19:03:58 CEST 2012


On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
> >> So that if you happen to have a "real" qmake instead of the wrapper in
> >> the
> >> PATH on linux, you don't realize that when you are doing "qmake -qt5" to
> >> force "most current qt5 version" (or whatever the semantics would be),
> >> you
> >> actually execute a completely different qmake? I don't think that would
> >> be
> >> a good idea.
> >
> > 
> >
> > It will do that too if it's in a separate build looking at a non-standard 
> > configuration path.
> 
> I don't get what you mean with that.

Er... convoluted way of saying that if you only have one Qt build visible from 
the wrapper, "qmake -qt5" can mean exactly one Qt build. Therefore, by 
exclusion of any other alternatives, it's the most recent build available :-)

In any case, "-qt5" may not mean "latest", but simply "default 5.x version". 
The implementation will decide what that means.

> > That's mostly what's going to happen on Windows anyway, 
> > isn't it?
> 
> My concerns are about having -qt5 ignored for the "real" qmake on linux. On
> Windows and Mac the -qt option is useless anyhow (which makes it
> questionable to use it there IMO, so it makes it questionable to use it in
> the documentation that way too IMO)
> 
> I think all this becomes much too confusing.

If the option is required in one platform and does not cause anything but a 
minor inconvenience on others, why not document it?

-- 
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/20121023/21750afb/attachment.sig>


More information about the Development mailing list