Open Source im professionellen Einsatz
Linux-Magazin 05/2013

Qmake für Fortgeschrittene

Großbaustelle

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.

581

Seine Anwesenheit bleibt oft unbemerkt: Qmake, das ursprünglich von Trolltech entwickelte Build-System für Qt-Anwendungen und die Qt-Bibliothek macht in vielen kleinen bis mittelgroßen Projekten meist einfach, was Entwickler erwarten. Wachsen die Projekte allerdings, dann wechseln viele Qt-Entwickler plötzlich zur Qmake-Alternative Cmake, die ursprünglich als Build-System für das ITK (Insight Segmentation and Registration Toolkit) entstand.

Als Begründung hört man dann meist, Qmake sei für viele Aufgaben schlicht ungeeignet. Im KDE-Projekt etwa ist Cmake das Werkzeug der Wahl, wenn es darum geht, große Mengen an Quellcode zu übersetzen. Klassische Build-Systeme wie Autotools, Ant und Ähnliche spielen in der Qt-Entwicklung aufgrund des höheren Integrationsaufwands indes kaum eine Rolle. Dass Qmake aber viel mehr kann, zeigt dieser Artikel: Mit dem Qt-eigenen Build-System lassen sich durchaus auch umfangreiche, plattformunabhängige Softwareprojekte schultern.

Qmake versus Cmake

Qmake weist durchaus Ähnlichkeiten mit dem bereits im Jahr 2000 gestarteten Cmake auf: Beide Systeme erzeugen aus einer Projektdatei ein »Makefile« , an dem sich »make« und »make install« entlanghangeln. Ungeachtet zahlloser Optionen, mit deren Hilfe der Codebauer das Erzeugen des Makefiles sehr genau kontrolliert, folgt ein typischer Build-Vorgang für Cmake und Qmake den Befehlen »cmake && make && make install« respektive »qmake && make && make install« .

So ähnlich die prinzipielle Vorgehensweise beim Build ist, so unterschiedlich fällt die Syntax der beiden Build-Dateien aus. Diese Unterschiede veranschaulicht ein kleines Beispielprojekt, das ein "Hello-World"-Programm übersetzt, welches aus den Komponenten »main.cpp« , »hellowindow.cpp« , »hellowindow.h« sowie »hellowindow.ui« besteht. Es beinhaltet einen Installer und Übersetzungen, auf die der Artikel später eingeht.

Hallo Doppelwelt

Cmake-Projekte zeichnen sich dadurch aus, dass sie üblicherweise eine Datei namens »CMakeLists.txt« im Top-Level-Verzeichnis des Projekts ablegen (Listing 1). Prinzipiell lassen sich aber auch mit diesem System Unterprojekte in Form weiterer »CMakeLists.txt« -Dateien einbinden, ganz so wie bei Qmake.

Listing 1

Hello-World-Programm als Cmake-Projekt

01 PROJECT(helloworld)
02 FIND_PACKAGE(Qt4_REQUIRED)
03
04 SET(helloworld_SOURCES main.cpp hellowindow.cpp)
05 SET(helloworld_HEADERS hellowindow.h)
06 SET(helloworld_FORMS hellowindow.ui)
07
08 QT4_WRAP_CPP(helloworld_HEADERS_MOC ${helloworld_HEADERS})
09 QT4_WRAP_UI(helloworld_FORMS_HEADERS ${helloworld_FORMS})
10 INCLUDE(${QT_USE_FILE})
11 ADD_DEFINITIONS(${QT_DEFINITIONS})
12
13 SET(QT_USE_QTCORE)
14 SET(QT_USE_QTGUI)
15
16 ADD_EXECUTABLE(helloworld ${helloworld_SOURCES} ${helloworld_HEADERS_MOC} ${helloworld_FORMS_HEADERS})
17 TARGET_LINK_LIBRARIES(helloworld ${QT_LIBRARIES})

Der erfahrene Qt-Entwickler weiß, dass vor dem eigentlichen Kompilieren und Linken noch einige Tools und Codegeneratoren an die Arbeit gehen. Qmake-Projekte definiert er in einer ».pro« -Datei, die idealerweise den Namen des Ordners trägt, in dem sie liegt (Listing 2). Dieses System weist – ähnlich wie das von Cmake – bestimmten Variablen Werte zu und beeinflusst den Kompiliervorgang mithilfe vordefinierter Schalter (Listing 2). Auch Qmake ersetzt nicht das klassische Make, sondern ist vielmehr eine Art Makefile-Generator.

Listing 2

Hello World als Qmake-Projekt

01 TEMPLATE = app
02 TARGET = helloworld
03 QT = core gui
04 SOURCES = main.cpp hellowindow.cpp
05 HEADERS = hellowindow.h
06 FORMS = hellowindow.ui

Der auffallendste Unterschied zwischen beiden Build-Systemen besteht darin, dass die Qmake-Syntax deutlich einfacher zu lesen und zugleich schlanker ist. Entwickler von Shellskripten sollten besonders gut mit ihr zurecht kommen, da sie sich eng an die Syntax der Shell anlehnt. Das rührt auch daher, dass Qmake die Eigenheiten der Qt-Bibliothek kennt und so viele Schritte im Hintergrund erledigt. Cmake dagegen ist von Zusatzpaketen abhängig, die nicht der Qt-Hersteller, sondern die Community pflegt.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 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

  • Buildsysteme

    Beim Erstellen von Software unterstützen Buildtools und Buildsysteme die Entwickler und ihre Teams. In einem Überblick zeigt dieser Artikel den Klassiker Make und seine Alternativen bis zu Maven und den Buildservices. Dazu gibt's Empfehlungen für den Einsatz in verschiedenen Szenarien.

  • 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.

  • 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.

  • Am Ball bleiben

    Software-Entwicklung erfolgt meist im Team. Die Zusammenarbeit bringt Impulse für das Projekt - sie kann es aber auch gefährden, wenn sich Qualitätsprobleme einschleichen. Ein Weg aus der Misere ist die Continuous Integration, Hudson das passende Tool.

comments powered by Disqus

Stellenmarkt

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