Ihre Software für die Übersetzung mit den Autotools portabel zu konfigurieren ist eine Aufgabe, die für viele Programmierer komplizierter als der eigene Code ist. Die Alternative Cmake verschafft den Entwicklern eine wohlverdiente Denkpause.

In- und Out-of-Source

In dem ersten einfachen Beispiel wurde Cmake im Wurzelverzeichnis des Quelltextbaums ausgeführt, dort startete auch »make« zum Kompilieren der Software. Das ist die herkömmliche Vorgehensweise, die bei Cmake In-Source-Build heißt. Zusätzlich unterstützt Cmake auch Out-of-Source-Builds, bei denen die Software nicht im Quelltextbaum kompiliert wird, sondern in einem beliebigen anderen Verzeichnis.

Out-of-Source- besitzen gegenüber den In-Source-Builds mehrere Vorteile: Der Quelltextbaum bleibt sauber und übersichtlich, er wird nicht durch Objektdateien oder andere Zwischendateien aufgebläht. Soll der Entwickler das Projekt komplett neu erzeugen, kann er einfach das ganze Buildverzeichnis löschen. Zu einem Quelltextverzeichnis darf er beliebig viele Buildverzeichnisse angelegen, etwa für ein Release- und ein Debug-Build. Um das obige Beispiel Out-of-Source zu kompilieren, legt er ein Buildverzeichnis an und startet Cmake dort. Wie beim ersten Beispiel ist der Pfad zum Quelltextverzeichnis das Argument. Listing 4 zeigt den Ablauf des Cmake- und Buildvorgangs.

01 ~/src $ mkdir myproj-build
02 ~/src/ $ cd myproj-build
03 ~/src/myproj-build $ cmake ~/src/myproj
04 -- Check for working C compiler: /usr/bin/gcc
05 -- Check for working C compiler: /usr/bin/gcc -- works
06 -- Check size of void*
07 -- Check size of void* - done
08 -- Check for working CXX compiler: /usr/bin/c++
09 -- Check for working CXX compiler: /usr/bin/c++ -- works
10 -- Configuring done
11 -- Generating done
12 -- Build files have been written to: ~/src/myproj-build
13 ~/src/myproj-build $ make
14 [ 20%] Building C object lib/CMakeFiles/util.dir/core.o
15 [ 40%] Building C object lib/CMakeFiles/util.dir/util.o
16 [ 60%] Building C object lib/CMakeFiles/util.dir/unixtool.o
17 Linking C shared library libutil.so
18 [ 60%] Built target util
19 Scanning dependencies of target fooapp
20 [ 80%] Building CXX object app/CMakeFiles/fooapp.dir/main.o
21 [100%] Building CXX object app/CMakeFiles/fooapp.dir/process.o
22 Linking CXX executable fooapp
23 [100%] Built target fooapp

Nach dem Kompilieren installiert das Kommando »make install« die Software. Die von Cmake erzeugten Makefiles stellen noch einige weitere Make-Targets zur Verfügung, eine Übersicht gibt »make help«. Ein weiteres Buildverzeichnis »myproj-build-2« soll im Folgenden dazu dienen, die Erzeugung von Kdevelop-Projektdateien zu demonstrieren, die Cmake ebenfalls beherrscht:

$ cd myproj-build-2
$ cmake ~/src/myproj -GKDevelop3
-- Check for working C compiler: /usr/bin/gcc
...
-- Build files have been written to: ~/src/myproj-build-2

Im Buildverzeichnis findet sich nun untere anderem die Kdevelop-Projektdatei »FooProject.kdevelop«, die sich mit Kdevelop öffnen lässt (Abbildung 2). Den Projektnamen bezieht Cmake vom »project()«-Befehl in Zeile 1 von »myproj/CMakeLists.txt«.

Abbildung 2: Die KDE-Entwicklungsumgebung Kdevelop mit dem von Cmake generierten Projekt. Neben den Quelldateien zeigt der Schnellöffner auch die Cmake-Projektdateien.

Bei Out-of-Source-Builds sind ein paar Dinge zu beachten. Im vorigen Beispiel nutzt die Anwendung Funktionen aus der Library »util« und verwendet dazu Header aus dem Verzeichnis »~/src/myproj/lib/«. Deshalb wird dieses Verzeichnis zum Include-Pfad des Compilers hinzugefügt. Dies geschieht in Zeile 1 von Listing 3c durch das Kommando »include_directories(${CMAKE_SOURCE_DIR}/lib)«.

Variablen

»CMAKE_SOURCE_DIR« ist eine von Cmake bereitgestellte Variable, die immer das Wurzelverzeichnis des Quelltextbaums enthält. Zum Navigieren im Quelltext- oder Buildverzeichnis-Baum kennt Cmake außerdem die folgenden Variablen: »CMAKE_CURRENT_SOURCE_DIR« steht für das aktuelle Verzeichnis im Quelltextbaum, »CMAKE_BINARY_DIR« enthält das Wurzelverzeichnis des Buildverzeichnisses (analog zu »CMAKE_SOURCE_DIR«) und schließlich zeigt »CMAKE_CURRENT_BINARY_DIR« auf das aktuelle Verzeichnis im Buildverzeichnis (analog zu »CMAKE_CURRENT_SOURCE_DIR«).

Beim Schreiben der Cmake-Dateien muss der Programmierer immer bedenken, ob er im Quelltext- oder im Buildverzeichnis arbeitet. Um in einem Projekt Out-of-Source-Builds zu unterstützen, ist Folgendes zu beachten:

• Relative Pfade in »CMakeLists.txt« sind immer als relativ zu dem aktuellen »CMAKE_CURRENT_SOURCE_DIR« zu verstehen, zum Beispiel entspricht »add_executable(hello main.c)« dem »${CMAKE_CURRENT_SOURCE_DIR}/main.c«
• Alle zu generierenden Dateien sollten entweder in »CMAKE_BINARY_DIR« oder »CMAKE_CURRENT_BINARY_ DIR« erzeugt werden. Das ist vor allem bei den Befehlen »configure_file()«, »file()« und »add_custom_command()« zu beachten. Bei ihnen ist immer der vollständige Pfad zu benutzen, etwa »${CMAKE_CURRENT_BINARY_DIR}/generated.h«.

Ein kleines Beispiel, das nur aus vier »CMakeLists.txt«-Dateien besteht (Abbildung 3), demonstriert die Funktion dieser Variablen. Jede dieser »CMakeLists.txt« gibt die vier genannten Variablen aus. Hier der Inhalt von »src/cmakevars/CMakeLists.txt«:

message(STATUS "${CMAKE_SOURCE_DIR} ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_BINARY_DIR} ${CMAKE_CURRENT_BINARY_DIR}")add_subdirectory(misc)add_subdirectory(app)

Abbildung 3: Die Dateistruktur zum Test der Cmake-Variablen besteht nur aus drei Projektdateien.

Die Listings 5a und 5b zeigen die Ausgaben von Cmake bei Out-of-Source- respektive In-Source-Benutzung.

01 ~/src $ mkdir cmakevars-build
02 ~/src $ cd cmakevars-build
03 ~/src/cmakevars-build $ cmake ../cmakevars
04 --  ~/src/cmakevars ~/src/cmakevars          ~/src/cmakevars-build ~/src/cmakevars-build
05 --  ~/src/cmakevars ~/src/cmakevars/misc     ~/src/cmakevars-build ~/src/cmakevars-build/misc
06 --  ~/src/cmakevars ~/src/cmakevars/misc/sub ~/src/cmakevars-build ~/src/cmakevars-build/misc/sub
07 --  ~/src/cmakevars ~/src/cmakevars/app      ~/src/cmakevars-build ~/src/cmakevars-build/app
08 -- Configuring done
09 -- Generating done
10 -- Build files have been written to: ~/src/tests/ca/cmakevars-build

01 ~/src/cmakevars $ cmake .
02 --  ~/src/cmakevars ~/src/cmakevars          ~/src/cmakevars ~/src/cmakevars
03 --  ~/src/cmakevars ~/src/cmakevars/misc     ~/src/cmakevars ~/src/cmakevars/misc
04 --  ~/src/cmakevars ~/src/cmakevars/misc/sub ~/src/cmakevars ~/src/cmakevars/misc/sub
05 --  ~/src/cmakevars ~/src/cmakevars/app      ~/src/cmakevars ~/src/cmakevars/app
06 -- Configuring done
07 -- Generating done
08 -- Build files have been written to: ~/src/cmakevars

Bei einem Out-of-Source-Lauf verändert Cmake die Werte der »*BINARY_DIR«-Variablen gegenüber In-Source. Das Prinzip dahinter: Die Variablen »*_SOURCE_DIR« zeigen immer in den Quelltextbaum, »*_BINARY_DIR« dagegen immer in die Buildverzeichnis-Struktur. Die »CMAKE_CURRENT_*«-Variablen beziehen sich immer auf das aktuelle Unterverzeichnis.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Ihre Software für die Übersetzung mit den Autotools portabel zu konfigurieren ist eine Aufgabe, die für viele Programmierer komplizierter als der eigene Code ist. Die Alternative Cmake verschafft den Entwicklern eine wohlverdiente Denkpause.