qmake versus CMake

[jcr]

Which one are you using? Any compelling reason to choose one over the other?

[wysota]

I'm using qmake. Not because I think it is better (it is not) but because cmake is an external dependency and it currently can't offer me any features I need that can't be obtained with qmake. If at some point cmake replaces qmake, I'll switch to cmake.

[fullmetalcoder]

most obvious reasons to use cmake I can think of :

• out-of-source-tree builds (I have yet to find a way to do that with qmake...)
• supports much more libraries/tools out of the box than qmake does (or is it up to distros to take care of that?)
• KDE uses (obviously only a good reason if you're working on KDE-based/KDE-oriented projects)

most obvious reasons not to use it :

• additional dependency (especially important for cross-platform apps since all linux distros ship it nowadays)
• poor documentation (or difficult to find, though it *might* have improved since I last checked)
• yet another new syntax to learn, and not the nicest one by far

I use qmake because

1. It does the job
2. I'm used to it (and came to know a lot about it through writing parsers and project manager)

[jpn]

out-of-source-tree builds (I have yet to find a way to do that with qmake...)

Works fine with qmake. Even Qt as a big and complex project can be built outside the source tree.

[fullmetalcoder]

Works fine with qmake. Even Qt as a big and complex project can be built outside the source tree.

Maybe I missed something but last time I checked qmake did not really appreciate it when the Makefiles where not inside the source tree. Any piece of wisdom on this topic would be appreciated as I'd really like to be able to make proper out-of-source-tree builds with qmake (OBJECT_DIR, UI_DIR, MOC_DIR and RCC_DIR are not enough I really need to prevent makefiles from polluting my source tree). And it'd be even better if it worked well with subdirs project without having to perform dark magic in every single project file...

[jpn]

Just to verify, you did try building OUTSIDE the source tree, right? I mean, not within a temporary dir next to the top level .pro file or anywhere else inside the source tree.

[SABROG]

Don't use CMake, becouse don't want write "CONFIG += console" implementation for each knowing compiler.

[fullmetalcoder]

Just to verify, you did try building OUTSIDE the source tree, right? I mean, not within a temporary dir next to the top level .pro file or anywhere else inside the source tree.

I'm afraid I don't quite see the distinction.
Let's say I have source package of software X which comes with qmake project files placed somewhere in the source tree (presumably at top level but that really shouldn't matter). I don't want to pollute that package I just unpacked so I go in some directory (temporary or not, near the unpacked software or not) and want to iniate a build process there and make sure all build files land there and none ever pollute the source tree. How do I do that with qmake?

Optimally it should be doable without altering the project files but even if it required relying on env variables and other tricks to get this working I'd be just as happy.

[jpn]

I'm afraid I don't quite see the distinction.
Let's say I have source package of software X which comes with qmake project files placed somewhere in the source tree (presumably at top level but that really shouldn't matter). I don't want to pollute that package I just unpacked so I go in some directory (temporary or not, near the unpacked software or not) and want to iniate a build process there and make sure all build files land there and none ever pollute the source tree. How do I do that with qmake?

Let's consider the following simple project hierarchy:

project
    project.pro
    subdir1
        subdir1.pro
    subdir2
        subdir2.pro

project
    project.pro
    subdir1
        subdir1.pro
    subdir2
        subdir2.pro

To copy to clipboard, switch view to plain text mode 

From my experience it is fine to create a build directory next to 'project' and run 'qmake ../project/project.pro'. However, usually you end up having problems if you create the build directory inside 'project' and run 'qmake ../project.pro'.

[ComaWhite]

I actually prefer CMake over QMake. Because I had a ton of problems setting up sub directories. KDE4 supports it and uses it heavily. And since my app uses KDE4 I have to use CMake. QMake it good for what it does. But it spits out all that verbose garbage that I can't stand seeing when problems are compiling just like with autotools. It's ugly. And alot more people are moving from autotools to CMake. It's much easier to write a FindFoo.cmake to find libraries on any OS and have it available. Like with Boost, Qt4. Qt3, KDE3, KDE4, OpenGL, etc.

CMake gives me a clear thing so it easier to see compiler warnings, colourful output, and percentage of how much has compiled and gone by which I totally love.

QMake is great for small trivial applications but once you go from there to more complex it just makes it totally much harder. Mandriva even rewrote Qt-Creator in CMake.

CMake's documentation might be a little shotty but its not that bad. Just take a little more time googling or asking in the #cmake channel on Freenode.

I won't QMake anymore. And I always use CMake for any programming projects I do even when not using Qt4 and KDE4.

[fullmetalcoder]

But it spits out all that verbose garbage that I can't stand seeing when problems are compiling just like with autotools.

Did you ever tried the silent mode? For a slightly nicer output I have written a small shell script which can parse make output and reformat it (requires sh and awk, no colors but should be trivial to add) which you can find in recent (and not so recent) Edyuk packages (it's called write_log).

QMake is great for small trivial applications but once you go from there to more complex it just makes it totally much harder.

That's really not true. qmake offers a LOT of flexibility (though most of it used to be undocumented and some features still aren't covered by the docs) allowing you to add extra "compilers" (or any other kind of file processor) for custom files type or for existing one (in fact moc, uic and rcc support are not hardcoded into qmake but provided through a couple of .prf files). Writing a .prf file is as easy as writing the equivalent FindX.cmake and using it from a project boils down to "CONFIG += X" (and any other variable assignement that may be needed for X to be of any use). In that domain the only big difference is the syntax (matter of taste/learning curve).

And I always use CMake for any programming projects I do even when not using Qt4 and KDE4.

funny, I use qmake for almost all my programming projects because it's just so damn easy to create a simple project (for small ones qmake -project is usually enough).

[wysota]

But it spits out all that verbose garbage that I can't stand seeing when problems are compiling just like with autotools.

"CONFIG += silent" fixes the "problem" as already noted.

And alot more people are moving from autotools to CMake.

Moving from autotools to any other project manager is a step in a good direction. It is obvious that people who don't use Qt will prefer cmake over qmake simply because qmake is usually distributed together with Qt and they don't need it. So the argument is very biased.

It's much easier to write a FindFoo.cmake to find libraries on any OS and have it available. Like with Boost, Qt4. Qt3, KDE3, KDE4, OpenGL, etc.

Everything is fine as long as everything is in standard places which is most often the case for different unices and Linux distribution but is a very rare case on Windows.

Mandriva even rewrote Qt-Creator in CMake.

They did? In what way? I have CMake support in Creator made by Nokia...

I won't QMake anymore. And I always use CMake for any programming projects I do even when not using Qt4 and KDE4.

Let's face it - cmake is a next generation tool compared to qmake just as qmake is a next generation tool compared to autotools or tmake. So this is obvious that many things are easier to obtain with cmake than with qmake because the former learned from the experience gathered by the latter. But this all doesn't change a fact that if you want to deploy a Qt based application in a foreign environment it is easier to do it using qmake than using cmake once you have the build infrastructure set up properly. So this is really a battle between easing the development stage and easing the installation stage. From what I've seen on QtCentre the latter yields more problems thus it is better if one experienced developer battles with qmake than if dozens of unexperienced Windoze end-users battle with both cmake (and its dependencies) and the final application itself. And let's not forget Qt needs to be deployed as well (in both cases).

So to sum things up - for Qt only applications I will prefer qmake over cmake as long as qmake is a standard build tool for Qt. For KDE4 applications I will prefer cmake over anything else because I'm not smart enough to setup my own build infrastructure for KDE applications. For other uses I can use either one or the other or even write a dedicated Makefile if neither is available.

[Tanuki-no Torigava]

I do prefer CMake because:
1. I can generate MVC and Code::Blocks project files;
2. I can use ctest, a nice subset of CMake where you can write arbitrary tests and run them with make check;
3. No more headache with M4 macroses in autotools;
4. CMake supports nice environment detection mainly limited in qmake.

The 3rd is actually not an argument because qmake has nothing to do with M4 macroses as well.

[ComaWhite]

Can QMake even do platform checks like you'd find in CMake and Autohell?

[fullmetalcoder]

Can QMake even do platform checks like you'd find in CMake and Autohell?

Depends what you mean with "platform checks"...

The use of scopes allow simple "conditionnalization" of builds based on platform and could easily be used for more elaborate checks, like the example scenario below :

• libA is a library that may or may not use Qt but whose developers a want to support qmake build system so they provide a .prf file for that purpose
• appB is an app that uses qmake as a build system and has libA as an optional dependency

A naive way of doing that is the following :

• name the prf file libA.prf (up to lib authors, all they have to do is be consistent about their choice and document it)
• add "CONFIG += libA" in appB project file
• besides include and lib settings, libA.prf adds defines that can be used within the source code to detect whether or not it is present

An extension of this scheme which would vastly improve the "auto-detection" would be to add something like "CONFIG += has_libA" in libA.prf so that appB project file could take extra measures to accomodate the optional dependency.

Besides, the builtin qmake functions and the ability to define new functions in qmake pro/pri/prf files enables easy version checking so the answer is a definite yes : qmake does support this kind of "platform checks". Unfortunately there aren't that many projects providing prf files, even among Qt-only projects so people end up thinking :

It's much easier to write a FindFoo.cmake to find libraries on any OS and have it available.

. While it's blatantly false. A truer statemement would be "It's much easier to find an existing FindFoo.cmake to find libraries on any OS and have it available."

[SixDegrees]

While my experience with cmake is limited, I utterly loathe it. It is poorly documented and buggy. It typically takes me far more time to hammer a cmake-controlled project into a shape in which it will actually build something than it does to perform the build itself.

Ask me again once it matures - say, in three to five years - and I might feel differently.

Qmake certainly has it's limitations - and is also not well documented - but at least it generally works.

[ChrisW67]

Let's consider the following simple project hierarchy:

project
    project.pro
    subdir1
        subdir1.pro
    subdir2
        subdir2.pro

project
    project.pro
    subdir1
        subdir1.pro
    subdir2
        subdir2.pro

To copy to clipboard, switch view to plain text mode 

From my experience it is fine to create a build directory next to 'project' and run 'qmake ../project/project.pro'. However, usually you end up having problems if you create the build directory inside 'project' and run 'qmake ../project.pro'.

Curious, I do this as a matter of course on Windows and Linux and have not had an issue. What sort of problems am I missing out on?

[Alir3z4]

I use QMake since the first article i'd read about Qt, those articles didn't mention that to use CMake to have colorful output or something.
But i like CMake, because it's uses alot by KDE community, and actually

CMake gives me a clear thing so it easier to see compiler warnings, colourful output, and percentage of how much has compiled and gone by which I totally love.

is really helpfull.
But i think it's personally, or technically :|

[Oleg]

Actually I use both, as qmake is good for quick start, but when project needs more flexible build control and portability, then I switch to CMake.

[anda_skoa]

Actually I use both, as qmake is good for quick start, but when project needs more flexible build control and portability, then I switch to CMake.

Indeed

Cheers,
_