[CMake] Annoyances with cmake vs qmake

Ruben Van Boxem vanboxem.ruben at gmail.com
Sun Mar 28 15:06:10 EDT 2010


Hi all,

Since qmake is pretty mouldy (I mean, not probable to be updated anytime
soon with new functionality), I decided to try cmake and its colourful build
process.

When experimenting with qmake, I "ported" libogg, libvorbis and libflac to a
qmake build system and it worked pretty easily, without many hiccups. Mind
you, I didn't add any assembly stuff to the builds, just source and build
options. And that brings me to my first point

1) in qmake and any other configure-based  build system, the release build
options for gcc/g++ are something like this: "-O2 -s". CMake uses "-O3".
This is neither standard nor recommended (see gcc docs, this option might
even produce slower code). It also forgets to strip the binary target, which
makes you end up with larger binaries. This should be changed, as "-O2 -s"
for release builds is pretty much the de facto standard.

2) A second point, and this has been brought up before on this list, several
times even. With qmake:
qmake
make debug //produces debug binaries
make release //produces release binaries
make all //produces both
make distclean //cleans out *most* of the qmake generated files

It shouldn't be hard to have each target's build dir have a debug and
release folder (even if it's only for windows stuff), and add the de facto
standard debug suffix d to the debug binaries. Even easier would be to have
all debug object files have the d suffix, eliminating the need for release
and debug directory clobber.
Additionally, the distclean target is pretty handy, but I've seen enough
argumentation (out-of-source builds) that convinces me it's not the CMake
way

So something like this would be AWESOME:
mkdir build
cd build
cmake ..
make debug //produce debug binaries
make release //produce release binaries
make all //produce both

A simple debug suffix will solve most problems with this I believe, and
seems to me, extremely handy for the windows platform. Then MinGW or Nmake
makefiles will be a standalone thing, like vcproj files, where it is
perfectly possible.

On a sidenote, CMake is very powerful and solid tool, and I'm really
starting to hate the whole configure script and libtool hell. Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100328/0ae9c4f1/attachment.htm>


More information about the CMake mailing list