[Qt5-feedback] Qt5's qmake

[Keith Gardner]

I would also like to see a new tool written from the ground up.  One thing I would like to see in a new tool that could be borrowed from CMake is a find library mechanism.  I like CMake's way of doing a platform dependent search for libraries and having the results given in a platform independent way in the form of variables.

An example is to search for Boost on a machine with all of its compile options.  It can be difficult on Windows when there are compiler options as well as build options that are used to make the library file name.

Keith

From: qt5-feedback-bounces+kgardner=zebraimaging.com at qt.nokia.com [mailto:qt5-feedback-bounces+kgardner=zebraimaging.com at qt.nokia.com] On Behalf Of Charley Bay
Sent: Thursday, May 12, 2011 9:20 AM
To: qt5-feedback at qt.nokia.com
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/6abf1fad/attachment-0001.html