LWN: Comments on "Why the KDE project switched to CMake -- and how (continued)"

Why the KDE project switched to CMake -- and how (continued)

halla — Fri, 10 Jul 2009 11:17:27 +0000

Was it around, stable and mature in 2005? Were there people in 2005 who
were prepared to work the KDE community to remedy any deficiencies? (Note:
the scons project wasn't prepared to cooperate with KDE, even though that
was the original choice.)

In the end, that's all to the good because CMake is really excellent.

Why the KDE project switched to CMake -- and how (continued)

arnuld_uttre — Fri, 10 Jul 2009 10:05:22 +0000

> Posted Jun 22, 2006 10:41 UTC (Thu) by aleXXX (subscriber, #2742)
> Today KDE 4 builds with cmake on more platforms than
> KDE 3 with autotools ever did, with full configure
> checking on all platforms and all compilers/IDEs.

I read your whole article and the *aloud message* I got was very few KDS developers are familiar with autotools, rather than autotools are not competitive to scons or cmake. And those developers are not willing to learn autotools.

Why the KDE project switched to CMake -- and how (continued)

arnuld_uttre — Fri, 10 Jul 2009 10:00:53 +0000

I wonder why KDE team did not try waf

Why the KDE project switched to CMake -- and how (continued)

zlynx — Thu, 06 Jul 2006 01:44:41 +0000

For a project like KDE, the amount of changes needed in the KDE code itself to port to a platform like AIX dwarfs the amount of code changes needed to make CMake run on that platform. So if it makes work easier on the common platforms, it is a better deal, and ports can still be done by porting CMake first.

As for autotools I have never seen them be that useful in porting. Sure, autotools may run on all sorts of systems but nothing out there tells you what autotools tests and variables your code needs to be checking for portability.

For example, assuming select() returns the remaining time from a timeout. If you develop on Linux and rely on that feature, then port to another Unix, autotools may have a test to detect that for you but you have to try the port and find the problem first before you even know you need it.

Why the KDE project switched to CMake -- and how (continued)

emptty — Wed, 05 Jul 2006 22:23:04 +0000

I am wondering about the availability of the cmake tool itself. The nice thing about autotools is that they generate plainly portable shell script. I agree that it does not solve the portability to windows and macosx well, but to port software to some exotic platform like AIX or simply solaris, it is precious.

I'm not denigrating cmake here, I just want to see if this tool is adapted to my own need.

Why the KDE project switched to CMake -- and how (continued)

nix — Fri, 23 Jun 2006 20:13:40 +0000

Mozilla, Python, GCC, Emacs, XEmacs... the list is long.

A brief scan of the packages I have unpacked here reveals 1319 using Autoconf, of which 835 use Automake.

Why the KDE project switched to CMake -- and how (continued)

jamesh — Fri, 23 Jun 2006 03:54:48 +0000

Some prominent ones that come to mind are Mozilla and Python. There are others, but autoconf is definitely used in more projects than automake (which is no surprise since automake requires autoconf but not vice versa).

Why the KDE project switched to CMake -- and how (continued)

aleXXX — Thu, 22 Jun 2006 14:11:10 +0000

I'm not sure there are many projects using autoconf together with
handwritten makefiles without automake and libtool.
CMake has compared to autoconf alone e.g. the advantage that it also
supports MSVC under Windows and that it can not only generate Makefiles,
but also project files (Xcode, MSVC, KDevelop3), which you cannot achieve
with handwritten makefiles.

Alex

Why the KDE project switched to CMake -- and how (continued)

akumria — Thu, 22 Jun 2006 12:36:02 +0000

> Today KDE 4 builds with cmake on more platforms than KDE 3 with autotools
> ever did, with full configure checking on all platforms and all
> compilers/IDEs.

autotools = automake + libtool + autoconf

What both the two previous posters were pointing out is that if you project is just using autoconf there may not be the same benefit in switching to cmake.

Why the KDE project switched to CMake -- and how (continued)

aleXXX — Thu, 22 Jun 2006 10:41:23 +0000

> Plus, of course, package vendors will kill you unless the generated
> makefiles support at least prefix= or DESTDIR=

DESTDIR is supported.

> Replacing Autoconf at least strikes me as a seriously retrograde step
> unless you don't care about portability: and I *know* that isn't true
> for KDE.

Today KDE 4 builds with cmake on more platforms than KDE 3 with autotools
ever did, with full configure checking on all platforms and all
compilers/IDEs.

Alex

Why the KDE project switched to CMake -- and how (continued)

aleXXX — Thu, 22 Jun 2006 10:35:40 +0000

Yes, CMake replaces all three of them.
It will create the Makefiles for you (... and project files if you want
to).

Alex

Why the KDE project switched to CMake -- and how (continued)

nix — Thu, 22 Jun 2006 09:46:03 +0000

One problem with a lot of alternative build system is that autoconf and automake permit substantial end-user adjustment. (Personally I have a rather elaborate config.site setting up compiler and linker options for different systems; embedded hackers tend to have even more elaborate config.site's). Most alternative build systems throw all of that away and provide very little alternative (I remember trying to get Jam to allow user-specified CFLAGS with horror).

Autoconf also embodies a lot of 'ancient wisdom' about detection of features available on all sorts of systems. I haven't found *any* other build systems that come close.

Plus, of course, package vendors will kill you unless the generated makefiles support at least prefix= or DESTDIR=.

Replacing Autoconf at least strikes me as a seriously retrograde step unless you don't care about portability: and I *know* that isn't true for KDE.

Why the KDE project switched to CMake -- and how (continued)

kleptog — Thu, 22 Jun 2006 09:40:36 +0000

I don't know about happy. I was just trying to clarify that a project using only autoconf but not automake would have to switch to CMake generated makefiles instead their own. That is, in CMake the configure step cannot be seperated from the automake step.

I'm just asking because while I'm not a great fan of autoconf, I'd only replace it with something that would let me keep my hand created makefiles.

Why the KDE project switched to CMake -- and how (continued)

aleXXX — Thu, 22 Jun 2006 09:23:39 +0000

For everybody who is happy with autotools there is no reason to switch,
for everybody else CMake is an alternative.

Alex

Why the KDE project switched to CMake -- and how (continued)

kleptog — Thu, 22 Jun 2006 09:20:53 +0000

I can see the benefits of tossing automake and libtool, but there are plenty of projects out there that use autoconf for configuration and standard makefiles for the building. I've looked at the website but I don't think CMake can provide much benefit for these projects.

Nice article though.

Why the KDE project switched to CMake -- and how (continued)

cventers — Thu, 22 Jun 2006 07:05:15 +0000

Nice read!