[Development] New proposal for the tool naming

[Stephen Kelly]

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.

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

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

$ qt 48
$ # Now I'm using self-built Qt 4.8 in ~/dev/prefix/qt48, and 
$ # CMAKE_PREFIX_PATH=~/dev/prefix/qt48
$ qmake # Do the expected
$ cmake # Do the expected
$ qt 47
$ # Now I'm using self-built Qt 4.7 in ~/dev/prefix/qt47, and 
$ # CMAKE_PREFIX_PATH=~/dev/prefix/qt47
$ qt 5-qnx
$ # Now I'm using self-built Qt 5.0 for QNX in ~/dev/prefix/qt50-qnx, and 
$ # CMAKE_PREFIX_PATH=~/dev/prefix/qt50-qnx. I also set a CMAKE env var to 
$ # find the correct CMAKE_TOOLCHAIN_FILE so I can cross compile.
$ qt undef
$ # Now I've turned off the env vars for self-built stuff and I'm using 
$ # what my distro provided.

My solution is based on sourcing files (not portable) and setting environment 
variables appropriately, so it would need to be implemented in a cross 
platform way

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. 

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

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.

So, I don't think stuffing this into a tool called 'qmake' has value. Let's 
rather call it qset, or continue to leave it to the developers to solve the 
problem themselves as they currently do. 

> [...]
> 
> > Additionally, this tool may support options like -add-qt and
> > -set-default-qt. I'm also open to adding an option -run-tool= (e.g.,
> > qmake -qt=5 -run- tool=qmlplugindump) if that's of interest to people.
> 
> If you are open to feature requests, here's another one: -store (or any
> better name) which stores the value of the "-qt=" option into
> 
>   $PWD/.qmake-config
> 
> which the qmake wrapper will use as default configuration when run from
> this directory with no -qt argument. That would allow one to do:
> 
>   cd ~/src/projectA
>   qmake -qt=5 -store
>   [...]
>   cd ../projectB
>   qmake -qt=5-mingw32 -store

This is what environment variables are for, as I wrote above. Environment 
variables also let the developer solve the whole problem, unlike qmake -store.

> 
> And from that time on one doesn't need to remember what qt version or
> toolchain one has to use for a project, and just always type "qmake"
> from the project base directory.

This is the right goal imo, but the wrong implementation.

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
** Qt Developer Conference: http://qtconference.kdab.com/ **
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121020/b59530fd/attachment.sig>