Open Source im professionellen Einsatz
Linux-Magazin 02/2007
© photocase.com

© photocase.com

Einführung in das Buildsystem Cmake

Mal ausspannen

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.

923

Als Linux-Nutzer hat man sich über die Jahre an die Schritte »./configure; make; make install« zum Kompilieren von Softwarepaketen gewöhnt. Hinter ihnen verbergen sich die Autotools, eine Sammlung von Shell-, M4- und Perl-Skripten, die dabei hilft, Software zu schreiben, die sich portabel auf verschiedenen Unix-Derivaten kompilieren lässt. Für viele Entwickler sind die Autotools aber wegen der Vielzahl ineinander greifender Programme eine große Hürde.

Ein alternatives Buildsystem namens Cmake [1] schickt sich nun an, "die Art und Weise, wie alle Software-Entwickler arbeiten, zu ändern", wie Bill Hoffman, einer der Cmake-Entwickler, es ausdrückt. Inzwischen setzt eine ganze Reihe kommerzieller und freier Projekte Cmake ein. Das größte und bekannteste ist derzeit KDE 4, das aus Millionen Zeilen Code besteht [2] und sich heute auf allen Plattformen (Linux, *BSD, Mac OS X, Windows mit Mingw wie auch den MS-Compilern) kompilieren lässt. Weitere Projekte sind Scribus, der Chicken Scheme Interpreter, das Strategiespiel Boson, Plplot und der Debian-Fork der CDR-Tools. Ethereal, Lyx, Open Wengo und Libgphoto sind gerade dabei, Cmake für ihre Zwecke zu evaluieren.

Cross-Plattform

Das Cross-Plattform-Make steht unter der BSD-Lizenz und wird von der amerikanischen Firma Kitware Inc. [3] entwickelt, die sich auf Visualisierungssoftware für medizinische Anwendungen spezialisiert hat. Cmake entstand im Rahmen des Insight Segmentation and Registration Toolkit [4] zur Visualisierung des menschlichen Körpers. Das Tool vereint die Funktionalität der verschiedenen Bestandteile der Autotools in sich:

  • Erzeugung von Makefiles
  • Unterstützung verschiedener Compiler und Linker auf unterschiedlichen Plattformen
  • Unterstützung von System-Introspection
  • Erweiterbarkeit durch Makros

Einzige Voraussetzung für den Einsatz von Cmake ist ein C++-Compiler. Daher funktioniert Cmake zum Beispiel auch unter Windows mit MS Visual Studio problemlos. Cmake ist aber nicht nur ein Makefile-Generator, es erzeugt auch Eingangsdateien für das native Buildsystem der jeweiligen Plattform.

So kann es unter Unix Makefiles und Projekte für Kdevelop 3 erzeugen, bei Mac OS X zusätzlich Projektdateien für Xcode und unter Windows Makefiles für Cygwin, Mingw, Msys, Borland und Microsoft Make sowie die IDEs von Microsoft ab Visual Studio 6. Unter Windows und Mac OS X dürfen Entwickler also auch mit Cmake weiter mit ihren gewohnten Entwicklungsumgebungen arbeiten und müssen nicht zurück auf die Kommandozeile.

Für die Qualitätssicherung unterstützt Cmake die Einbindung von Unit-Tests, Nightly Builds und weiteren Tools wie Valgrind [5] oder KWStyle [6]. Die Ergebnisse sammelt ein zentraler Dart-Dashboard-Server [7].

Hallo Welt

Alle Beispiele in diesem Artikel setzen Cmake 2.4.3 oder neuer voraus. Das Tool liest Dateien mit dem Namen »CMakeLists.txt« (Groß- undKleinschreibung beachten) ein und generiert daraus die gewünschten Makefiles beziehungsweise Projektdateien. Im folgenden Hallo-Welt-Beispiel die Datei »main.c« soll zu einem Programm kompiliert und dann gelinkt werden:

#include <stdio.h>
int main()
{
   printf("Hallo Welt!n");
   return 0;
}

Die zugehörige »CMakeLists.txt« sieht wie folgt aus:

add_executable(hallowelt main.c)

Der Cmake-Befehl »add_executable()« bedeutet, dass aus der Quelldatei »main.c« ein ausführbares Programm namens »hallowelt« entstehen soll. Cmake beachtet dabei die plattformspezifischen Eigenschaften, das Executable wird also unter typischen Unix-Systemen den Namen »hallowelt« bekommen, unter Windows dagegen »hallowelt.exe«.

Cmake erwartet (Listing 1) als Argument jenes Verzeichnis, in dem der Quelltext und die »CMakeLists.txt« liegen. Hat Cmake die »CMakeLists.txt« im aktuellen Verzeichnis gelesen, einen Compiler gesucht und Makefiles erzeugt, kann der Entwickler sein Projekt schließlich übersetzen (Listing 2).

Listing 1: Konfigurieren

01 ~/src/hallo/ $ cmake .
02 -- Check for working C compiler: /usr/bin/gcc
03 -- Check for working C compiler: /usr/bin/gcc -- works
04 -- Check size of void*
05 -- Check size of void* - done
06 -- Check for working CXX compiler: /usr/bin/c++
07 -- Check for working CXX compiler: /usr/bin/c++ -- works
08 -- Configuring done
09 -- Generating done
10 -- Build files have been written to: ~/src/tests/hallo

Listing 2: Übersetzen

01 ~/src/hallo $ make
02 Scanning dependencies of target hallowelt
03 [100%] Building C object CMakeFiles/hallo.dir/main.o
04 Linking C executable hallowelt
05 [100%] Built target hallowelt
06 ~/src/hallo $ ./hallowelt
07 Hallo Welt!

Nach diesem recht einfachen Einstieg folgt nun ein komplexeres Projekt, das weitere Fähigkeiten von Cmake vorstellt. Es besteht aus einer Library und einem Programm, das diese Library benutzt. Die Quellen sind wie in Abbildung 1 organisiert. Im Verzeichnis »myproj/lib/« soll aus den Dateien »core.c«, »util.c« und – je nach Plattform – »unixtool.c« oder »wintool.c« eine Shared Library »libmyutils.so« entstehen, im Verzeichnis »myproj/app/« außerdem ein Programm »fooapp« aus den Dateien »main.cpp« und »process.cpp«.

Abbildung 1: Der Verzeichnisbaum des Beispielprojekts mit insgesamt drei Projektdateien »CMakeLists.txt«.

Dieses Programm benutzt Funktionen aus »libmyutils.so«, das heißt, dass der Compiler beim Übersetzen von »fooapp« die Header »core.h« und »util.h« finden und der Linker »myapp« zu »libmyutil.so« linken muss. Nach dem Buildvorgang soll Cmake das Programm und die Library installieren. Die Inhalte der einzelnen »CMakeLists.txt« zeigen die Listings 3a bis 3c.

Listing 3a: »myproj/CMakeLists.txt«

01 project(FooProject)
02 add_subdirectory(lib)
03 add_subdirectory(app)

Listing 3b: »myproj/lib/CMakeLists.txt«

01 set(libSrcs core.c util.c)
02 
03 if (UNIX)
04    set(libSrcs ${libSrcs} unixtool.c)
05 else (UNIX)
06    set(libSrcs ${libSrcs} wintool.c)
07 endif (UNIX)
08 
09 add_library(util SHARED ${libSrcs})
10 
11 install(TARGETS util DESTINATION lib)

Listing 3c: »myproj/app/CMakeLists.txt«

01 include_directories(${CMAKE_SOURCE_DIR}/lib)
02 
03 set(fooappSrcs main.cpp process.cpp)
04 add_executable(fooapp ${fooappSrcs})
05 
06 target_link_libraries(fooapp util)
07 
08 install(TARGETS fooapp DESTINATION bin)

Die Datei »myproj/CMakeLists.txt« verzweigt mit »add_subdirectory« in die Unterverzeichnisse »lib« und »app«. Cmake erwartet daraufhin in beiden Verzeichnissen jeweils eine »CMakeLists.txt«, die es verarbeitet. Alle anderen eventuell vorhandenen Unterverzeichnisse ignoriert Cmake.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 7 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Qmake vs. Cmake

    Größere Projekte, die Software auf Basis von Qt entwickeln, greifen gern zu Cmake, um den Code zu übersetzen. Dabei eignet sich das Qt-eigene Build-System Qmake durchaus auch für den Bau umfangreicher Anwendungen. Es beherrscht Shadow-Builds und kennt Abhängigkeiten für Pre- und Postbuild-Targets.

  • Qt-Software testen

    Wer zuverlässige Software schreiben will, kommt um Absturzversuche in kontrollierter Umgebung nicht herum. Qt-Entwickler dürfen sich glücklich schätzen, dass ihre Klassenbibliothek bereits Hilfsmittel zum Bau von Crashtest-Dummys enthält. Das Tool Ctest bereitet danach die Bruchstücke übersichtlich auf.

  • FOSDEM 2008: Buildsysteme bauen und testen Software

    Am Sonntagmorgen der europäischen Entwicklerkonferenz FOSDEM waren Build-Systeme ein Themenschwerpunkt.

  • Microsoft setzt auf Cmake

    Einen Fork gibt es bereits. Künftig möchte Microsoft Code liefern, dank dem Cmake von Hause aus den Windows Store und Windows Phone Apps unterstützt.

  • LLVM 3.8 rangiert viele Funktionen aus

    Die LLVM Compiler Infrastructure ist in Version 3.8 erschienen. Sie verabschiedet sich von alten Windows-Versionen, tauscht Autoconf gegen Cmake ein und rangiert verschiedene C-API-Funktionen aus. Für die Plattformen gibt es ebenfalls zahlreiche Änderungen.

comments powered by Disqus

Ausgabe 09/2016

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.