[pacman-dev] Humble proposal: replace autotools by CMake for pacman

Xavier shiningxc at gmail.com
Sat Jan 9 13:51:41 EST 2010

On Sat, Jan 9, 2010 at 7:28 PM, Jeff Horelick <jdhore1 at gmail.com> wrote:
> 2010/1/9 Yannick LM <yannicklm1337 at gmail.com>
>> Hi,
>> First of all, since it's my first message on this list, a few words
>> about myself:
>> I'm a French software engineer in a small company, I've use Arch from
>> several years now, and CMake at work.
>> (We produce a big piece of software written in C++ that must run on
>> windows, linux and mac)
>> I'm also a huge fan of the Python language.
>> Also, a few words about cmake:
>> Web page: http://www.cmake.org/
>> Typical workflow is:
>>    cd /path/to/source
>>    mkdir build
>>    cd build
>>    cmake ..
>>    ccmake . #optional, to change configuration
>>    make
>> Pros :
>>  * Nothing gets generated anywhere but in source/build, so there's no
>> need for "clean" rules and a .gitignore containing "build" is enough
>> :)
>>  * It's widely used, so lots of stuff such as using gettext is easily done.
>>  * It's fast! (written in C++)
>> Cons:
>>  * It has a ugly syntax
>>  * It lacks decent documentation:
>> http://cmake.org/cmake/help/cmake-2-8-docs.html is all you've got.
>> Back to the subject: one day I decided it would be great to see
>> libalpm wrapped in Python (or Ruby, or whatever ...)
>> It's quite easy done once you use swig, and swig is easy when you use
>> cmake.
>> So, I started hacking a few CMakeLists files.
>> The result is in a "cmake" branch in
>> git://sd-5791.dedibox.fr/prog/pacman.git
>> (which I'll try to keep not too far from pacman's official master branch)
>> Right now, here's what those files can do:
>>  * let the user choose a few variables such as CONFFILE, DBEXT,
>> LOGFILE (using ccmake)
>>  * build libalpm and pacman
>>  * install some files.
>> If you want, I could take care of everything that's still missing:
>> documentation,
>> translations, tests ...
>> I don't have much spare time to spend on this, but there's no need to
>> hurry, isn't it?
>> Just let me know if you are interested or if you have any question on
>> the subject.
>> Cheers,
>> Yannick LM
> I personally think CMake is a bad idea to use for something like pacman.
> It's a bit saner and easier to use, but it's HUGE (~24MB on disk) compared
> to autotools (~4MB on disk) and to build CMake itself takes quite a while
> (~20 minutes on a fairly decent 2.8GhZ Pentium 4 under no load). While I
> dislike autotools, I think for critical system components, using CMake is
> too heavy and a bit stupid.

I don't like autotools either but probably because I do not understand
it. And I do not not other build systems either , so ... :)
Just for reference, another alternative that was proposed some times ago :

More information about the pacman-dev mailing list