When building something I usually either let an IDE handle the build process, or write makefiles manually. Both solution work, but have drawbacks. IDEs allow you to forget about how code is built, but create some sort of IDE lock-in, since switching to another IDE becomes difficult. Makefiles solve this problem, but are a bit too low level, and writing makefiles for complex projects is tedious.
So it’s a while I’ve been searching a better way. The most known alternative is autoconf and automake. If you’ve compiled some software on Linux you’ll be familiar with the
./configure <options> make make install
way of doing things. However, these tools have the main problems of being built mostly with shell scripts. If you plan to support only Linux this is not an issue, but it becomes a bigger trouble if your program needs to be compiled on windows too, where bash is not available by default.
Recently I’ve found CMake, and it looks interesting. First it’s the tool used to build KDE4, and this means it’s well suited even for large projects, second it claims to work equally well on Linux, Mac and Windows. And lastly, its syntax seems simple and high level.
I’ve started with the documentaton on its website, and in 15 minutes I’ve been able to compile an example program. The example program is made of three files, main.cpp, foo.cpp and foo.h.
The first step to create a CMake project is to write a file named CMakeLists.txt. Its content is this:
cmake_minimum_required (VERSION 2.6) project (HELLO) add_executable (hello main.cpp foo.cpp)
The first line is a requirement for a new version of CMake. The second specifies the name of the project, and the third tells CMake to create an executable named hello by compiling the files main.cpp and foo.cpp. Really simple.
Like autoconf and automake, CMake doesn’t compile the code directly, instead it generates a makefile. The steps to compile the example program are to open a shell in the directory where the source files and CMakeLists.txt are, and type:
mkdir build cd build cmake ../ make
This is because with CMake it is recomended to keep the build directory separated from the source directory. To remove the generated files it is either possible to type “make clean” or simply to delete the build directory.
It is still early to say if I’ll use CMake for my projects, after all I’ve just started using it for 15 minutes, but it surely looks interesting.
September 16, 2009 at 8:05 pm |
Usually, you put the source files in a CMake variable, like SET(hello_SRCS main.cpp foo.cpp), and then use it in the add_executable command.
Anyway: welcome to the CMake world!
September 16, 2009 at 8:32 pm |
Nice to know someone else at POuL is using it.
I should have guessed it from the fact that you’re developing for KDE (yes, I read your blog)
Now I have someone to ask questions about CMake 🙂
September 17, 2009 at 12:21 am |
And now it’s time for me to ask 😀
How does the whole stuff handle dinamically linked libraries? 😀
September 17, 2009 at 10:41 am |
Well, as soon as I’ll find it out, I’ll post it on my blog 😉
The things I’ll need to understand are (in order)
1) How to link with dynamic libraries and static libraries
2) How to create libraries (static and dynamic)
3) How to pass custom commands to the compiler (like -O2 to optimize for speed, -s to strip the executable…)
4) How the option system works
But all this after my thesis…
November 4, 2010 at 7:04 pm |
[…] fedetft It’s not the first time I talk about CMake in this blog, for the introduction read here. Now it’s time to explore the CMake syntax further. The first CMakeLists.txt looked like […]
November 4, 2010 at 7:04 pm |
[…] not the first time I talk about CMake in this blog, for the introduction read here. Now it’s time to explore the CMake syntax further. The first CMakeLists.txt looked like […]