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 <[email protected]> | 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/ **
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
