[pacman-dev] Humble proposal: replace autotools by CMake for pacman
Yannick LM
yannicklm1337 at gmail.com
Sat Jan 9 12:12:53 EST 2010
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
More information about the pacman-dev
mailing list