Submitted by KDE is ditching the GNU autotools for development and building of their next version, KDE 4. Its replacement is CMake, developed by Kitware. Alexander Neundorf explains the choice in favor of CMake was mainly due to its support for all platforms KDE4 is meant to run on: Linux, BSD, Mac OS X, Solaris, and even Windows. CMake generates specific command files for each of the ‘native’ build tools from one common source: Makefiles (for GNU make) or project files (for XCode on OS X, for MS Visual Studio, for KDevelop3). Current KDE 4 modules already build (with CMake) on more platforms than KDE 3 with autotools ever did, with full configure checking on all platforms and all compilers/IDEs. Scribus is now also moving to CMake.
don’t want to sound like a downer, but I’m skeptical on this. as it was, kde build setup has been one of the best I’ve seen for any large scale project like it. that is, from the perspective of a pacakager.
I realize it wasn’t (or at I’d hope it wasn’t) a decision taken lightly, but love them or hate them, the autotools essentially represent something akin to a standard in *nix world that folk are used to dealing with. it’s when project decides they want to be ‘clever’ and different, and decide to setup up their source tree like nobody else does that they become a problem to deal with, especially for folk like me who aren’t doing compiles for just a single local machine. (thankfully at least it does look like cmake is smart enough to understand DESTDIR, otherwise I’d be much more unhappy about this.)
I would be very surprised if they didn’t consider packaging when they decided to switch. I used to follow the KDE mailing lists and i have read countless mails about problems with the build system, and there really was very few people who groked it.
I made a small KDE project and i doubt i would ever have gotten it to work had i not taken an existing setup and tweaked it, so i think replacing the autotools with something simpler is a very big step ahead. I’m a developer, time spent fiddling with the build system is time wasted, and learning arcane things that is useless out of autotools land seems pretty wasteful to me too.
If CMake prooves difficult to work with for packagers then i see no reason why they wouldn’t work with the packagers to fix that, just like they worked with the KDE developers.
I would be very surprised if they didn’t consider packaging when they decided to switch
Be surprised then ! It seems they didn’t. When asked how someone can tweak the build to make it work on their system or for adaptation, they evade the question.
It seems it will be harder than with autotools.
I made a small KDE project and i doubt i would ever have gotten it to work had i not taken an existing setup and tweaked it, so i think replacing the autotools with something simpler is a very big step ahead
You should just have used the KDE IDE (forgot the name, sorry).
I’m a developer, time spent fiddling with the build system is time wasted, and learning arcane things that is useless out of autotools land seems pretty wasteful to me too
Depends on what you want to do. If you just want to make your own project you’re right. As soon as you want to deploy your project, and assure it will work on many different architectures on POSIX (or sort of) OS, then this time spent is everything but a waste. The small learning curve then allow you to deploy your project easily.
If CMake prooves difficult to work with for packagers then i see no reason why they wouldn’t work with the packagers to fix that, just like they worked with the KDE developers
That’s one of the benefit of CMake. But I see CMake like a big regression from autotools. That’s also one more compilation system to install on your OS.
I don’t care as long as I never have to tweak the build system to make a KDE build work. But I have high doubt it will be the case.
IMHO, all this chatter is just to drown readers in sugar coat, to not make them see the true reasons behind the move.
To me, the real reasons behind this move are :
– It produces files for Apple and MS Windows build systems, which is not a goal of autotools. Nothing bad with that, except that it means now, that these requirements force a big overhaul on the project, while some KDE devs and fans assured us that Windows support would not impede development of the main free platforms.
– CMake is written in C++. KDE coders are familiar with C++. Perhaps they didn’t realise it, and didn’t choose it knowingly for that.
– The myth that autotools is hard, like explained in the article, may be too hard to overcome. In case of KDE, it’s specially harder because of more hooks caused by moc and friends.
The problem was, that KDE didn’t use a standard autotools setup because they had a special need for things like moc (meta object compiler) generated files, uic etc. So they created an intermediate layer, the infamous am_edit (crude perl hack). This also why they had to maintain their own buildsystem that nobody really understood. CMake is much more flexible and extensible in that area.
With am_edit, there where several tools involved, making it overly complex: autoconf, automake, libtool, am_edit, all with different versions and incompatilities.
And don’t worry about DESTDIR, that’s a standard feature.
All in all, I welcome the change. The CMake buildsystem is much cleaner.
This also why they had to maintain their own buildsystem that nobody really understood. CMake is much more flexible and extensible in that area
That’s just not true. You will be hard pressed to be more flexible than autotools. How can you say that CMake is more flexible, when it mixes three different build operations in one ? If you want to use only one of these steps, either you can’t, or you’re still forced to keep the two other components.
Extensibility is also a big advantage of autotools. The truth is that developers will still have to take time learning CMake. They didn’t take this time for autotools.
IMHO KDE devs hope that the fact that CMake has still no myth of being hard to use, and the fact that it is a C++ coded tools, will help them actually try to learn it.
All in all, I welcome the change. The CMake buildsystem is much cleaner
I hope it will work well. I still don’t welcome anything until the first time I compile KDE4.
IMHO, KDE devs are doing lots of dangerous (read uncertain) moves for KDE4. On the other hand, what better time for these changes, than a jump in major version ?
From the perspective of a developer, autotools is absolutely horrible. It’s phenomenally opaque. I’ve worked with the sourcecode of kdelibs and kdebase, and dealing with autotools was a dark spot in an otherwise very nicely organized codebase.
From the perspective of a developer, autotools is absolutely horrible
I doubt it. It’s harder than having a simple makefile, for sure. There is a reason for that.
It’s phenomenally opaque
Actually it’s not, but you have several things to learn to master it.
I’ve worked with the sourcecode of kdelibs and kdebase, and dealing with autotools was a dark spot in an otherwise very nicely organized codebase
Autotools do not touch your codebase, except for some define and ifdef.
Autotools are for preparing your build environment for it to automagically work on every architecture (that use gcc and gnu make).
Why then, do you mix working on the source code, and working with the build environment ? Just to make autotools look bad ?
I wonder when KDE devs will readily admit that the main reason for CMake is to build with MSVC and XCode.
From the perspective of a developer, autotools is absolutely horrible
I doubt it. It’s harder than having a simple makefile, for sure. There is a reason for that.
To me, autotools are horrible. They’re also not fully documented and the main examples you have to work with are existing software out there which rarely does things in a consistent fashion. For a person that has never developed auto* scripts it’s very daunting. The documentation you have to learn and read is spread out, and it hasn’t been updated in a while. In addition, the various auto* tools have a lot of quirks under operating systems other than Linux that are really annoying.
In general, I don’t like using autotools. I just write my own makefiles by hand, it’s far easier than messing with autotools.
Actually it’s not, but you have several things to learn to master it.
You can say that about anything. Doesn’t mean it’s not an opaque thing to use compared to anything else you could be. Automake, autoconf, libtool, m4….. It’s awful to put together as a developer.
Typical KDE. Get the fundamentals right so that developers can do more and build from there. It’s absolutely fundamental to an open source, and especially a desktop, project with relatively few programming resources.
It’s great to see KDE (and Scribus) move from the broken, tacked-together GNU autotools to a cleaner, platform-independent solution. It’s high time for such a shift.
I honestly cannot understand why a Qt based project isn’t using QMake. QMake is cross platform also, works perfectly and is easy in use. Considering the relationship between Trolltech and the KDE community I don’t get it….
I think the BIG reason why Qmake wasn’t used was because the criterion for a replacement was: a) Had to be less painful than ‘auto-hell’ b) Had to have a friendly licence c) Had to be actively developed d) Had to be production ready, and e) Had to have developers who were amenable to KDE’s needs–
After that it was a race to see who could come up with a working build system. It seems that Cmake won that race, and everybody seems more or less content with that. The basic working premise was that, “Code Speaks”.
From http://blogs.qtdeveloper.net/archives/2006/05/14/cmake-in-kde/
KDE needs a build system that supports flexible configure checks since it uses a lot of 3rdparty libraries. An easy and portable way of finding if a library is installed in the propery version on a system, if a header provides the correct prototype of a function, if a compiler supports a certain option.
Unfortunately that is a feature that qmake does not provide currently.
Edited 2006-06-29 20:27
I know there was a lot of discussioon about using bksys/SCons for KDE 4. Even so much, that appearantly it was “decided” at academy that it would be the build system for KDE 4:
http://dot.kde.org/1126452494/
But I missed why/how was this changed, and replaced with CMake. I am not familiar with CMake, but have heard many good, and bad opinions about it. So I just hope it will work for KDE. Autotools was kinda too complex and confusing, and many people didn’t really like it.
nvm. should have read the entire article instead first.
Edited 2006-06-29 22:27
I remember this for sure
There were some technical issues with scons, and the upstream developers seemed unreceptive to making changes (or accepting patches). The KDE developers feared having to maintain a separate heavily patched (basically ‘fork’) of scons… Hence the a-e criteria of my previous post.
I think QMAKE is not free. The old TMAKE is, but not QMAKE.
hopefully its not too much work to make Solaris a supported build platform.
I’m glad to hear that the Scribus developer got CMake working after just 10 minutes. I’ve looked at incorporating autotools before but they do have terrible error messages, so I’ve continually just stuck with a plain ol’ hand-maintained non-portable Makefile. My projects are miniscule in comparison to KDE, but the same principle applies: The build system should not be an obstacle to development but rather a facilitator.
I totally agree with you. This is the transiion, FreeBSD should make.
“The build system should not be an obstacle to development but rather a facilitator.”
I couldn’t say it better. Howver, autotools are not bad. But they need an overhaul.
First CVS to Subversion, then Auto* to CMake, whats next?
Bugzilla to Trac?
“Bugzilla to Trac?”
Or maybe launchpad
…Or maybe launchpad
I doubt it.
As long as it closed source, launchpad is off the table.
“Or maybe launchpad”
That’s certainly an interesting option. As soon as Launchpad [ http://en.wikipedia.org/wiki/Launchpad_(website) ] is released as open source software under an acceptable license…
*burb* launchpad?! Hopefully never, Bugzilla is far more easier and nicer to use… (Or is it just KDE’s bugzilla that is?)
I heard/read a while back that KDE was switching to SCons?! Which “news” item is true?
“I heard/read a while back that KDE was switching to SCons?! Which “news” item is true?”
If you care to really learn the answer, you should read the article linked in the OSAlert news snippet above. For your convenience, here’s the URL (again):
[ http://lwn.net/Articles/188693/ }
Have fun.
> I wonder when KDE devs will readily admit that the
> main reason for CMake is to build with MSVC and
> XCode.
that certainly was one of the reasons for selecting CMake (and one of the place auto* falls down), but the primary reason is that we had had enough of auto* and the pain it continuously inflicted upon us. we want something that was easier to work with, was faster and had some of the features unsermake gave us. auto* wasn’t exactly a picnic even for those of us who concentrate pretty exclusively on linux as our dev platform.
“I doubt it. It’s harder than having a simple makefile, for sure. There is a reason for that. ”
Yeah, and the reason is ~500K of complex and intertwined shellscript, perl and m4.
“Actually it’s not, but you have several things to learn to master it.”
And with CMake you only have to learn one syntax. Wonder which one is easier and more transparent…
“I wonder when KDE devs will readily admit that the main reason for CMake is to build with MSVC and XCode.”
And perhaps also to make is easier on non-Linux platforms in general. You see, the ironic thing about autohell is that while it exists primarily to make building on different platforms easier it only really works well on very few platforms.
Although I will miss the autohell unintentional hilarity of the pointless checks it makes for even the smallest project, like checking for Fortran.