[Development] New proposal for the tool naming

[Thiago Macieira]

On sábado, 20 de outubro de 2012 10.28.35, Stephen Kelly wrote:
> On Saturday, October 20, 2012 10:30:36 Alberto Mardegan wrote:
> > On 10/20/2012 02:16 AM, Thiago Macieira wrote:
> > [...]
> > 
> > > 3) In addition, we'll create a *new* tool also called qmake that will be
> 
> I wonder how FindQt4.cmake will react to that. If that module finds Qt 5 it
> is supposed to keep looking for Qt 4. I'm not sure how it would react to
> qmake suddenly being a perl script instead of qmake.exe for example.

The idea is that Linux distributions will make this tool default to Qt 4. So 
if the user does nothing, FindQt4.cmake will continue working.

If the user does something to select Qt 5, that is the user's fault. It's 
equivalent to setting today's qmake first in $PATH.

> Why not use a tool of a new name? Why overload the meaning and responsiblity
> of qmake?

Because everyone is complaining of having a new name.

> > As you seem to hint in the follow-up e-mail, this is not limited to
> > 
> > version numbers, but can contain toolchain information:
> >   qmake -qt=5
> >   qmake -qt=5-mingw32
> >   qmake -qt=4.8-maemo5
> > 
> > Right? If so, that would be excellent.
> 
> ... but only useful for Qt, not for the whole environment. I have a bash
> function called qt (and a similar one called kde) which lets me choose an
> environment where Qt is my focus, but not the limit to what I want access
> to. That is, I also want my cmake to find the correct Qt, which means
> setting the CMAKE_PREFIX_PATH environment variable.

Yeah, to be honest I'll probably keep my own shell function too. I still need 
to set the source directory for my shadow builds and it might not be easy to 
find it with qmake variables. But if it works, I'll replace mine.

> My whole point here is that developers don't use only qmake, and qmake isn't
> the only tool that should do different things when a different Qt is
> desired. You'll want a different toolchain and tools and everything.

True, but many of those settings can be found by inferring from qmake. If it 
doesn't work, then yeah, get the from somewhere else.

> The easiest way to achieve that is probably to create a solution based on
> files and you create a ~/.config/qconfig-maemo5 which shadows the one in
> /etc/qconfig-maemo5 and adds what you want. (Assuming the -add-qt option
> described below would be implemented to find files like that, but you get
> the idea).

Do you want to store more settings in the config file? Ok... I can consider that 
a feature request.

> Therefore, developers will still need to write their own tools which set
> environment variables (as you can see, I implemented my own tool similar to
> qset). I don't think there's any point in 'solving' the problem only for
> finding Qt, and not for the supporting required tools.

Oh, yeah, this is based on setting an environment variable. A tool can't set 
an environment variable, you need to write your own wrapper.

-- 
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/20121020/6312af80/attachment.sig>