[pacman-dev] Humble proposal: replace autotools by CMake for pacman
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
2010/1/9 Yannick LM
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.
On Sat, Jan 9, 2010 at 7:28 PM, Jeff Horelick
2010/1/9 Yannick LM
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 : http://mailman.archlinux.org/pipermail/pacman-dev/2008-June/006837.html
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.
Good points you've just mentioned here. Did not think of it.
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 : http://mailman.archlinux.org/pipermail/pacman-dev/2008-June/006837.html
Yup. Well, I guess xavier's answer will be good to keep as a reference, too. Sorry for the noise. Yannick LM
participants (3)
-
Jeff Horelick
-
Xavier
-
Yannick LM