[CMake] Annoyances with cmake vs qmake

Ruben Van Boxem vanboxem.ruben at gmail.com
Wed Mar 31 09:29:04 EDT 2010


2010/3/28 Hendrik Sattler <post at hendrik-sattler.de>

> But if you ever want to leave the very narrow path of what qmake is
> supposed
> to do, you are virtually doomed :-(
>

Correct, hence my switcheroo to CMake (and of course the colourful and clean
makefile build has something to do with it :)

"gcc -s" is only convenient for e.g. qmake because it only has one install
> target. In cmake, you have "make install" and "make install/strip", so you
> can
> decide at a later point. And even later, you can always use strip directly
> to
> achieve exactly the same. Choosing -O2 would really be preferred, but you
> may
> as well argue for -Os or anything else. You should always set the preferred
> thing yourself, see (C|CPP|CXX|LD)FLAGS environment variables.
>

Agreed on the -s part, but I still don't like a standard -O3 that, according
to documentation, make your built binary perform worse.

No, because when compiling differently for Debug and Release, you have all
> object files twice. Thus you would enforce one more level of subfolders
> even
> for those that only want one setup.
> There may be a new Generator that does that but it still has to be written
> ;)
>

I agree the additional subfolder level may be unwanted, that's why I
suggested the debug object file suffix to work around / solve the problem.
IMHO that's a clean way of seperating the debug vs release object files.

And to Eric: I consider an extra script along with CMake's part in this
superfluous. Why can't CMake mimic that behavior and let a user/dev use make
(dist)clean? And about the multiconfig single build: yes indeed, for larger
projects like WxWidgets or Qt this would be a requirement, as often devs
will develop with a debug build (for obvious reasons) and then use the
release build for their... release.
And yes, the CMAKE_DEBUG_POSTFIX is a good thing and I use it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100331/dc128bbc/attachment.htm>


More information about the CMake mailing list