Submitted by When a project with the size and scope of KDE gets to be as big as it is, sometimes changing a decision established almost a decade earlier is very difficult. KDE has relied on autotools to build most of the project since its inception, but for the last year, KDE 4 has been building with CMake, a newer build system that is rapidly becoming a heavyweight contender. Read on for more.
The Road to KDE 4: CMake, a New Build System for KDE
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
almost all of the KDE developers would now be considered CMake newbies. The CMake developers have been personally involved in ensuring that KDE’s transition is as smooth as possible.
Good to see such a close relationship between the KDE and CMake devs. I knew about the move to CMake but not really much about it, though judging purely on the comments in this article it’s going to be a great improvement for KDE and a good system for many other projects too.
Being a Gentoo user, the “CMake searches for dependencies several times faster than the ‘./configure’ process did. CMake builds KDE 4’s kdelibs about 40% faster than autotools build KDE 3.5.6’s kdelibs” bit sounds good.
I’ve always found build times a disadvantage for KDE apps. (It’s worth it though.)
Edited 2007-02-23 03:36
judging purely on the comments in this article it’s going to be a great improvement for KDE and a good system for many other projects too.
Yeah, that was sort of the purpose of this article. CMake is really a great buildsystem (it has it’s quirks too), but it’s really helped KDE a lot during the KDE 4 developer cycle. So, we thought it’d be a good thing to post about our good experiences so that other projects may consider CMake as well. Maybe raise awareness for CMake, after all they’ve done for us.
CMake rules – absolutely. It’s much better capable of doing incremental builds, which saves a lot of time.
Don’t get me wrong. I have absolutely nothing against KDE but WTH. Do we really need an article about every little piece of KDE4? What’s next? “The Road to KDE 4: New Desktop Icon”?
…Other projects have been switching to CMake too, including (but not limited to): Scribus, Rosegarden (switched from SCons), PlPlot, ChickenScheme, and more. …
It’s not only about KDE in reality …
Pretend this is an article about cmake then. It’s an interesting build system with which not many people are familiar.
At any rate, this isn’t a “little piece of KDE.” It’s a large fundamental change. People may recall Patrick dropped Gnome support from Slackware because of the difficulty inherent in building it. KDE was easier, and cmake should make it even more so. It’s worthy news imho.
And you’re taking me all wrong which is what I said not to do. Yes cmake is big news, a year ago when they announced they were moving to it. I don’t normally bitch about what articles get posted on OSN but this is getting ridiculous. Why not one comprehensive article? Some of us are capable of reading multi paragraph articles. Or we could just wait for the Release announcement/Release notes, if/when they finish building this beast.
Troy Unrau puts out this weekly article, which I don’t think is too often as long as they stay interesting.
Why not one comprehensive article? Or we could just wait for the Release announcement/Release notes, if/when they finish building this beast.
The whole point of this series of articles is to keep interest high for KDE4 by showing progress that is being made. Waiting for the official release would just result in a lot of comments about KDE4 being vaporware, as Thom’s article did before these articles started coming out.
I honestly don’t understand these claims of KDE being vap-o-ware that people try to float around. One can simply go to svn.kde.org and view all their code so far.
I believe a better term would be “work in progress”.
In a way, maybe it’s better. Otherwise you get all those comments b*tching about issues that aren’t really there, just because they look at the WIP as if it was the final release.
Edited 2007-02-23 07:40
The last article about okular had someone spouting off about how okular wasn’t as polished as evince or the mac’s doc viewer. I think he got about 10 replies or so, all telling him that you can’t expect a pre-alpha release to be more polished than released software. Some people just have no common sense. 🙂
Edited 2007-02-23 07:49
Actually, one of the future articles is about the new Oxygen theme. I don’t see what your problem is. This is a series of articles, each about a completely different topic. They’re also very good articles. They’re meant to show how kde is developing while the process is still ongoing. As far as I can tell, your complaint is that you don’t have to wait months and months for the actual release, to read one enormous article (at which point you could just use the software).
They’re also very good articles.
I like the idea of the series, and I agree with the other comments to the extent that the articles keep interest in KDE4 high and claims of vaporware low, but I think that many of these articles suck, quite frankly.
This one was pretty good, but some of the others were extremely bad. The first one on Decibel comes to mind. So if Troy is still reading this thread, keep doing the article series, but work a little harder on the articles. For instance:
Give a good overview of what the particular component does (it’s purpose and rationale) in the second paragraph, right after the teaser. I don’t want to read about the history of pdf viewers in KDE before finally getting a good idea of how Okular is different somewhere in the middle of the article.
More screenshots, code/shell snippets, and other visuals. It breaks up the text and keeps the reader’s interest. I know for a fact that CMake has a nice UI for configuring builds, but you didn’t show it, and instead claimed that you can’t show screenshots of a build system. This simply isn’t true. You could have shown how KDevelop integrates with CMake, and you could have also demonstrated a “hello world” CMakeLists.txt file.
you’re confusing “the road to kde4” series (which troy authors and this article is one of) and “the pillars of kde4” series (which is done by someone else, and which the decibel articles are a part of). think of it like “CSI” and “CSI: New York”, they have the same theme but topics and quality may vary. =)
you do have some interesting ideas though .. perhaps you could conspire with troy or nathan or one of the other writers to help make things even better
you mention kdevelop .. that’s something that is starting to come into its own as well, btw, and would do well with an article in the next while.
Edited 2007-02-23 05:48
“think of it like “CSI” and “CSI: New York”, they have the same theme but topics and quality may vary. =)”
Just like “CSI: Wanne-Eickel” and “CSI: Stasi”. 🙂
But back on topic: I found the article quite interesting allthough I’m not a KDE developer (and surely won’t be). The article furthermore mentioned the use of SNV (obsoleting CVS) for source control of KDE.
At least, cmake seems to need less dependencies than the classical way due to the optimized toolchain.
#
# A “hello world” CMakeLists.txt example
#
message(“hello world!”)
There, now are you satisfied?
Edited 2007-02-23 06:55
This one was pretty good, but some of the others were extremely bad. The first one on Decibel comes to mind. So if Troy is still reading this thread, keep doing the article series, but work a little harder on the articles.
Fortunately for me, I wasn’t the one responsible for the Decibel article. That one was produced by the KDE-promo team, a mostly ineffective design-by-committee type group. I write my articles on my own time and independent of any KDE influence. I usually go directly to the developers of a given component for my information rather than spend time bikeshedding with the promo folks.
Regarding your other suggestions, yes I could have wrote all of that content and made the article twice as long, but most of it is already covered in the various links I provided. I try not to get too technical, as my audience is mostly non-developers.
i have also tried using autotools and cmake, both in kdevelop and outside, and i must say, i NEVER had anything but trouble trying to manage autotools, hell, i gave up, its a freaking mess, i simply found it MUCH more managable to have a build bash script, where i wrote it all manually, it worked, was fast, and i could do that. since then i have been testing cmake, and it really just works, it also adds nice progress showing to the build process
not required, but nice nonetheless.
I’m glad to see I’m not the only one cursing automake.
Well, maybe the maturity is still using autotools, but I think the maturity is also cursing autotools.
Btw.: There are computer science professors (Technical University Vienna) who insist that their students have to use autotools, just because they never heard of anything else! And I’m thinking of a particular professor who isn’t that old that he could have lost touch which the current world of computer science. I think the new systems like scons[1], waf[2] and cmake[3] need more media attention!
Apropos: A comparison article between scons, waf and cmake (and maybe autotools) would be a very nice thing.
[1] http://scons.org/
[2] http://www.freehackers.org/~tnagy/bksys.html
[3] http://www.cmake.org/HTML/Index.html
autotools are fairly hard to use but the real problem for me was the horrible lack of documentation for newbies. Now I’m quite familiar with them and I have even used many of the advanced features they offer but this has costed me a lot of time reading info files and even peeking into autoconf’s sources. CMake looks way easier to learn and as a plus can be used in already ‘autotoolized’ projects without disrupting the existing infrastructure. However not being too familiar with it I wonder if it offers all the most advanced features of the autotools.
Autotools are actually fairly easy to use. What is hard, as always, is to grasp how it works. And there is plenty of documentation and tutorial for that.
The hardest part, is actually to find these tutorials, for beginners. They should be linked directly on the automake and autoconf pages. Only the general documentation is, and that’s not what you want.
The hardest part of autotools must be m4, which is a new macro description language you have to learn.
I find autotools are still better than CMake, for the few things I know about CMake.
Basically, CMake was no better than autotools for KDE, but contrary to autotools makers, CMake makers had time to listen to KDE devs, and helped them.
You won’t see that from autotools makers, as autotools are already well established.
Also, I see some KDE devs are still dishonest at best. Because the main reason for CMake, is actually that it can make project files for MacOS, Visual Studio and specific Kdevelop ones too. Of course, it would be harder with autotools, which is not made for that, AT ALL.
Also, it is not made to scale to KDE kind of projects, which is basically an archive containing several projects, and you must be able to compile selectively one or several of them.
This article is completely dishonest too, as the toolchain for cmake also includes sh and perl, and the one for autotools doesn’t require automake, autoconf or m4. That’s a pure lie. A project made with autotools shouldn’t need anything more than sh, libtool and make to build : that’s its purpose, and that’s why it’s slow !
Also, I see some KDE devs are still dishonest at best. Because the main reason for CMake, is actually that it can make project files for MacOS, Visual Studio and specific Kdevelop ones too.
While this is indeed a nice side effect, this is not the reason we switched to CMake. We knew at the outset of KDE 4 that we’d be moving away from autotools, since it got too messy for such a large project with so many custom generated files. SCons was our first candidate, but the SCons developers were unreceptive to changes we were suggesting in order to make it more modular and so forth. After several months of struggling with SCons, CMake support was added in days. Being able to build XCode, KDevelop, etc. project files was not the reason we chose CMake.
This article is completely dishonest too, as the toolchain for cmake also includes sh and perl, and the one for autotools doesn’t require automake, autoconf or m4. That’s a pure lie. A project made with autotools shouldn’t need anything more than sh, libtool and make to build : that’s its purpose, and that’s why it’s slow !
Well, you obviously haven’t taken a very close look. CMake has no perl dependencies.
And KDE did require automake, autoconf, and m4, the reason being that the ./configure script was not hand coded. KDE 3.x (and earlier) in CVS/SVN had no ./configure script, and so forth. This had to be autogenerated when you checked KDE out from the repository by running
‘make -f Makefile.cvs’
It needed to be regenerated every time you added/moved/renamed/etc. a single file to KDE. This whole system was very slow, and KDE had invented ways of speeding up this toolchain, including an optional in-house rewrite of automake (called unsermake) which sped the process up significantly, but introduced a python build dependency.
Also, libtool was probably the main offender for poor compilation performance. Simply losing libtool from the toolchain accounts for most of the build speed gains we’ve obtained for KDE 4.
You’ve got to remember that KDE isn’t pure C++, we’ve got all sorts of other things to deal with when building. XML-defined config classes, dbus interface classes from XML, documents to generate from raw source, Qt moc file to generate from the headers, .ui files to compile that create the code powering dialogs, translation files to generate, and so forth. Writing ./configure and Makefiles by hand is pretty much a nightmare when you get to a project of KDE’s size, so we had to resort to automake and autoconf. So no, it is not a lie. Those were our old dependencies, and our new dependencies are cmake and make.
I should have said “one of the main reasons” CMake was chosen, instead of “the main reason”, OK.
And I agree with you about the dev build stage of KDE. What bothers me is that with your comparison, you mixed the dev build phase and the release build phase. The build phase of KDE never required the autotools or even m4, unless you modified some code, but this wasn’t said. And the perl dependancy is entirely a choice of yours, not a dependancy brought by the autotools.
And I don’t deny either that the KDE build system with autotools was a mess. What bothers me, is that you say that goes with using autotools, which is not true at all.
Had you said that the autotools authors had no will to help you, I would understand.
And I know most of the problems KDE had was linked to the fact that you use C++, that you used the special preprocessor of Qt (moc), and that you wanted to generate XCode or VS projects.
> that you say that goes with using autotools
let’s put it this way then: autotools doesn’t scale to the size and complexity of a project such as kde without it becoming an exercise in almost constant pain and suffering. we simply outgrew what autotools could reasonbly provide.
i personally don’t care about windows and macos support (i understand the benefits for the project, etc, but it doesn’t directly improve my life in any form) and cmake has made my kde devel life much easier now that the build system is non-arcane, faster and smaller.
the transition way painful, but it has paid off huge dividends already.
i personally don’t care about windows and macos support (i understand the benefits for the project, etc, but it doesn’t directly improve my life in any form)
I think autoconf/automake is a complete pile of crap, and anyone who has tried to use it for non-trivial cross-platform builds probably thinks the same. I am quite happy to learn m4, automake syntax etc as long as it actually delivers on cross-platformness, but it doesn’t.
I would like to not have to care about Windows and Mac OS X support, but a large percentage of QtRuby users need it. Autohell problems have really inhibited the growth of the QtRuby community, and consequently QtRuby has a reputation for being very difficult to build on Windows and Mac OS X (you have to use a combination of autoconf/qmake/extconf to get it built). I expect once I have a release with cmake builds working properly on Windows and Mac OS X, and building a qtruby gem, the QtRuby user base will be at least 5 times larger.
If we can assume for a second that I’m too lazy at the moment to look this up for myself…
Does anyone know of the reasons that stop more people from moving away from autotools? What would be really interesting is if anyone can say why they’ve chosen autotools recently, over any of the alternatives.
I have a lot of respect for what autotools has done, and what it can still do; but these days it’s starting to look the hack it is. The idea of still using shell scripts and stepping through build steps in sequence as written is hardly fitting for modern systems.
Is it really just tradition and stability? Is there actually nothing that’s reached equivalent portability maybe? Any answers would be appreciated, thanks!
dgfsdgsdgsdfg
I just recently moved a 30k line project to CMake, and I have not regretted it. The CamelCase filenames and some of the syntax _is_ a bit dorky. But it really does the job with much less fuss even than straight Makefiles, let alone my previous autotool nightmares.
My CMakefiles are half the size of my old combination of Makefiles and shell scripts, and FAR less contorted.
I expect a huge number of Open Source projects to start switching now that KDE has pushed CMake into proven maturity.
anything but trouble trying to manage autotools, hell, i gave up, its a freaking mess, i simply found it MUCH more managable to have a build bash script, where i wrote it all manually, it worked, was fast, and i could do that.