Which one are you using? Any compelling reason to choose one over the other?
qmake
CMake
Which one are you using? Any compelling reason to choose one over the other?
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.
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
- It does the job
- I'm used to it (and came to know a lot about it through writing parsers and project manager)
Current Qt projects : QCodeEdit, RotiDeCode
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...
Current Qt projects : QCodeEdit, RotiDeCode
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.
J-P Nurmi
Don't use CMake, becouse don't want write "CONFIG += console" implementation for each knowing compiler.
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.
Current Qt projects : QCodeEdit, RotiDeCode
Let's consider the following simple project hierarchy:
Qt Code:
project project.pro subdir1 subdir1.pro subdir2 subdir2.proTo 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'.
J-P Nurmi
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.
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).
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).
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).And I always use CMake for any programming projects I do even when not using Qt4 and KDE4.
Current Qt projects : QCodeEdit, RotiDeCode
"CONFIG += silent" fixes the "problem" as already noted.
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.And alot more people are moving from autotools to CMake.
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.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.
They did? In what way? I have CMake support in Creator made by Nokia...Mandriva even rewrote Qt-Creator in CMake.
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).I won't QMake anymore. And I always use CMake for any programming projects I do even when not using Qt4 and KDE4.
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.
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.
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
is really helpfull.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.
But i think it's personally, or technically :|
...یه مرد هیچوقت زمین نمیخوره
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.
Oleg Shparber
Bookmarks