[Qt5-feedback] Qt5's qmake

[Ian Monroe]

On Thu, May 12, 2011 at 09:19, Charley Bay <charleyb123 at gmail.com> wrote:
> 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?

I don't find that side note link very persuasive. The issues
identified with cmake seemed rather esoteric. I mean, when did Google
need a reason to engage in Not Invented Hereism? We're all still
surprised they didn't fork the kernel.

cmake is a powerful system. Any technical and usability shortcomings I
think could and should just be addressed. It already has a lot of
traction in the community. And the Kitware folks are cool.

Anyways my biggest problem with qmake is the lack of configuration
system. An important requirement of open source software is that its
reasonably easy to build and configure. Otherwise the guarantees of a
open source license would just be theoretical. qmake (when its used
for anything beyond the very simple), with its lack of configuration
support, assumes that everyones systems are the same. This works fine
in proprietary environments. But any open source project using qmake
simply does not take open source seriously (or they have
rolled-their-own configuration system, like Qt itself does).

So whatever qmake+1 is, it shouldn't let configuration be an
afterthought. And I hope we just use cmake.

Ian Monroe