[Qt5-feedback] Qt5's qmake

[Charley Bay]

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/eff89b10/attachment-0001.html