Many of the things I choose to write are actually designed for cross-platform use. After all, there is import free platforms like the BSD's, as well as various forms of GNU/Linux. And even those users unfortunate enough to be on non-free platforms deserve a little freedom in their lives now and then, too.
Historically I used autotools, and I even came to use anjuta a long time ago because it can act as a smart IDE for autotool based projects and it could directly parse automake projects. It also integrates nicely with gdb for debugging. Anjuta of course is in active development and is found in the Ubuntu repositories.
What I do dislike about anjuta is the integrated editor (GtkSourceView), as I find it far too limiting. Incidentally the other editor plugin alternative for anjuta, scintilla, is broken in the current Ubuntu archives. But in regard to GtkSourceView, if you do not use tabs, but instead use spaces for tabs, it does not understand how to backspace through indents the way vim can. When you highlight "matching" braces and parenthesis, it unfortunately only highlights the "far" end, and not both braces the way most other source editors do, which I truly find annoying. And then there is the need to indent or outdent blocks of highlighted code, something I seem to do rather frequently. Perhaps though I have simply been spoiled on vim and emacs.
Of course, I could have learned to live with anjuta's editing limitations as one can easily invoke a generic though non-integrated external editor easily enough, but for it's lack of cmake support. As we have many people working on many diverse platforms, and often different IDE's in GNU Telephony, we found it a long time ago rather useful to begin adopting cmake to create builds alongside autotools. In fact, with the GNU ZRTP stack, Werner Ditterman recently has made the entire build and packaging process work in cmake, and for new packages, particularly GUI ones, I am already thinking of using exclusively cmake for their builds going forward.
It's always fun to try and integrate cmake with something to create a useful IDE driven build and debug environment. In theory it is supposed to be easy, in practice, often not clearly so without a lot of work. Certainly cmake generated results can be used in anjuta, in a rather limited way with it's backend support for generic Makefiles. It can as I have found however be wrestled into qtcreator to create a more complete IDE on GNU/Linux that is also entirely cross-platform.
Actually I originally had considered codeblocks, which is also cross-platform. But unfortunately cmake could not seem to be used to create codeblocks projects with multiple configurations (such as debug vs release or static vs dynamic libs) that you can switch between. Instead, they have to be done as separate stand-alone projects and seemed no better than the makefile integration with anjuta.
qtcreator actually is a nice, if rather lightweight and sometimes I think too simplified, general purpose cross-platform IDE, rather than just being Qt specific the way most people may assume. One thing it does is support direct switching between different cmake configurations within the same project just fine, though the process to actually set it up is rather obscure. Another thing is that the editor knows what a backspace is over a space indented file. In fact, it also does something I do with custom autobuffer rules in vim, which is automatically convert the file to the tab format currently specified when it is saved, and trim off trailing whitepaces.
KDevelop integration with cmake is said to be rather good, but I had not tried it as I personally prefer things like xfce4. I see nothing wrong with KDE for those who do choose it, and many interesting ideas are being explored in that desktop project. I would expect KDevelop to support multiple cmake build configurations, and offer gui integration of the cmake-gui style forms for setting build configuration, so I hope it does these things, rather than simply offers a means to build makefiles based on a single configuration behind the scenes which it then parses. Otherwise it would seem no better than say codeblocks or eclipse cmake support. Perhaps someone who has used KDevelop with cmake knows how well they work together.