lubuntu-desktop team mailing list archive

[PCMan <pcman.tw@xxxxxxxxx>]

Hi,
Since many people agreed that autotools is aged, horribly slow, complicated,
poorly documented, and hard to use correctly, I'm currently doing some
experiments with CMake, yet another build system.
KDE uses CMake since 4.0 and many other projects are migrating to it.
However, CMake has no built-in support for intltools, which is extensively
used in LXDE for translations.
In additon, few people use it with gtk+ programs written in C.
Fortunately, it's easy to extend CMake so I wrote a module for intltools and
created a simple gtk+ project.
Now it works well. I added a small project in lxde/devtools repo for demo.

http://lxde.git.sourceforge.net/git/gitweb.cgi?p=lxde/devtools;a=tree;f=gtk_cmake_test;h=ef2ea280444f8553e8a13b9053d216f8a46beb67;hb=HEAD

To build the demo project.
mkdir build
cd build
cmake ../
make
sudo make install

What we will get if we migrate to CMake:
1. colorful build log with progress display (in percent)
2. very fast!! much faster than autotools
3. clean source tree. No more autogen.sh, configure.ac, Makefile.am, and
many mysterious files.
4. well documented syntax with good readability. No more m4 macros mixed
with shell script.
5. easy to write, maintain, debug, and extend.
6. many user-contributed modules exists on internet
7. out of source build which does not pollute the source tree with generated
files
8. CMake is cross-platform. It can generate makefiles even for Windows.

What we will lose (but these are not hard to solve):
1. some nice tools designed for autotools integration, such as gtk-docize,
intltoolize, .... However, writing modules to support them is not difficult.
2. the build process may change a little. there will be no configure &&
make. use cmake ../ && make
3. many Makefile.am and configure.ac need rewrite
4. some feature checking macros provided by autoconf may not be available in
cmake and needs some work.

After playing with CMake for two days, I found it easy to use and extend.
It's a quite handy build system. I can understand why KDE switches to it. It
may be helpful for our project if we can use CMake to replace autotools.
After all, autotools create as many problems  as that is solves. Sometimes
debugging automake stuff takes more time than real coding and this greatly
decrease productivity. So I'd suggest a migration to CMake.

Any comment?
>From package maintainers' perspective, will using CMake make packaging
process more difficult? If the answer is no, I'd suggest a migration and
deprecate autotools.
Thanks.