[Qt5-feedback] Qt5's qmake

[BRM]

might I add that it needs to be able to function recursively very well.

Presently I have a number of projects where to keep things simple, I use 
sub-folders to manage portions of the code.
For example, in a protocol library I push chunks of the protocol (e.g. 
calibration) into its own folder.
However,  presently I have to be very careful about the naming of all the files  
throughout the entire project as no two of them can be the same;  otherwise 
QMake will build both, but only one object file will be kept  for linking. This 
is a rather simple thing that QMake should be able to  handle internally.

Note: We didn't want "yet another tool", so  CMake didn't make it into the 
picture. Otherwise we might be on CMake as  opposed to QMake. I generally like 
QMake; but there are a few major  short-comings, like the above, that could 
really improve the ability to  work with it.

Ben

P.S. Charley - sorry, meant to send it to the list the first time.


>
>From: Charley Bay <charleyb123 at gmail.com>
>To: qt5-feedback at qt.nokia.com
>Sent: Thu, May 12, 2011 10:19:43 AM
>Subject: [Qt5-feedback] Qt5's qmake
>
>
>I wanted to "awaken" the topic of Qt5's approach to qmake, expanded on Danny's 
>comment on the "Thoughts About Qt 5":
> 
>From Danny:
>Fix qmake. It doesn’t scale well and getting it to work on non-trivial products 
>requires hacky undocumented variables and tricks (see QtCreator’s own pro 
>files). If you can’t fix it, switch to CMake.
 
I agree with Danny that qmake doesn't scale to larger projects, but am not crazy 
about going to CMake with its own idiosyncracies.  Yes, it is a hard problem.
 
There is a very good pattern in qmake, cmake, and Google's Gyp ("generate your 
projects") to maintain the project configurations in some convenient format, and 
"generate" native projects/makefiles as needed.  Even Scons does this to 
generate native *.vcproj/*.sln with an "auto-moc" (which we use, but we extended 
somewhat).
 
I'm a big QtCreator fan, but that's an IDE, and not really a configuration 
manager.  I don't think it will ever be a configuration manager, nor do I think 
that is appropriate.
 
Real people with real code bases have hundreds of projects, including static 
libraries/assemblies, shared libs/DLLs, and EXEs.  Because of the "moc" step, it 
can be significant "work" to add a new file to a "project" where that project 
previously had no knowledge of the "moc" process (and, of course, adding the 
link dependencies).
 
IMHO, the build/packaging issues with Qt will be increasingly significant since 
the forward-looking direction is greater modularization and 
configuration-management/versioning of the Qt code base (a direction I 
support).  Further, the cross-platofrm targettign, such as for different mobile 
devices (with their own weird build-and-deployment steps) in addition to the 
(cross-platform) desktop, and with the added layer of new technologies like QML 
that introduce their own resource bundling/deployment issues.
 
My vote would be a new tool, from the ground-up, using greater heuristics, 
emphasizing simple/clean project configuration definitions.  IMHO, the "new 
tool" would be more qmake-like (simple to use), and less cmake-like (can be 
complicated syntax, but is very powerful), where the "new-qmake-like-thingie" 
would simply scale better and require less user specification for the "simple" 
stuff.
 
(Side note:  Very good overview as to why Google's "gyp" is not based on CMake:  
http://code.google.com/p/gyp/wiki/GypVsCMake)
 
Thoughts?
 
--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt.nokia.com/pipermail/qt5-feedback/attachments/20110512/7006aa30/attachment.html