Sergej Ferlich

Almost every project depends on Thirdparty software like Boost or QT. For building those projects, the compiler and linker need to know where they could find includes and which libraries they should link. But how should the programmer should know where the user has installed his Thirdparty-components?

CMake provides the command find_package().

This command uses special find-scripts called findPackageName.cmake and fills standard-variables which then give information about where and if libs ands includes are installed. Find-scripts are located at /usr/share/cmake/Modules on Linux systems. CMake already brings with scripts for the most used packages. A lot of components install their own scripts.

There are additional parameters for find_package() which allow the programmer to just search for certain versions or subcomponents of the Thirdparty. There also is a flag REQUIRED which will cancel the build-process if the requested Thirdparty is not installed.

Because code says more then thousand words:

 

The source searches for the QT4-components QtCore, QtGui and QtXml in version 4.4.3 and cancels, if they are not installed. The variables QT_USE_FILE and QT_LIBRARIES will be filled and could be used for the further build-process. There are a lot of other variables besides that two. For a complete list take a look at the CMake documentation.

This article already gives a short introduction on how to create patches with SVN and what they’re good for. Now I’ll talk about how to review and apply patches.

The command svn diff creates a textual summary of changes in a specific revision. Even with small changes, those textfiles aren’t very easy to read. KDevelop with its builtin Patch Review tries to solve that problem.

After selecting the base (mostly thats our project), the user chooses a .diff-file which contains the changes of the patch. A dialog shows files affected by it. By doubleclicking specific files, the code will be displayed in the editor.

The screenshot above shows a red X, marking that the light-blue area has been deleted in the patch. By clicking that X the change will be accepted.

This way a patch could be reviewed a lot easier. It’s simply viewing all files and choosing if a specific change should be accepted or not. After reviewing the whole patch, the button “Finish Review” could be clicked, which applys the patch.

Während der Arbeit mit Projekten anderer (seien es Arbeitskollegen oder OpenSource-Projekte) findet man ab und an Bugs, die sich mit Zugriff auf den Sourcecode leicht selbst beheben lassen.
Doch wie kommuniziert man diese Änderungen nun? Oft hat man keinen Schreibzugriff aufs SVN und selbst wenn, möchte man nicht einfach im Code des Kollegen rumwurschteln.


Subversion bietet die Möglichkeit, alle Änderungen in eine diff-File zu exportieren. Dies ist eine einfache ASCII-Datei die zusätzlich zu den einzelnen Änderungen jeder Datei auch die Revision enthält, mit denen diese gemacht wurden. Sogut wie jeder bessere Texteditor erkennt .diff und kann Syntax-Highlighting auf diese Dateien anwenden. Ein Programmierer, der diese Datei erhält, kann alle Änderungen nachvollziehen und anwenden.


Im einzelnen sehen die Schritte so aus:

1. Zunächst wird das Projekt aus dem Repository ausgecheckt und alle Änderungen an den Dateien vorgenommen.
2. Mit dem Befehl svn diff erhält man eine Auflistung aller Änderungen. Der Befehl svn diff > myfirstpatch.diff schreibt diese Auflistung unter Linux in eine Datei.
3. Zusammen mit weiteren Anmerkungen (vielleicht per Mail oder in einem Bugreport) sendet man die Patch-Datei nun an den anderen Programmierer.
4. Dieser sollte sich die .diff genau ansehen. Natürlich können Patches auch schädlichen Code beinhalten. Unter Kollegen wird dies nicht vorkommen, aber bei anonymen Patches in Opensource-Projekten ist die Wahrscheinlichkeit schon höher.
5. Ist der Patch in Ordnung, kann dieser unter Linux mit dem Befehl patch -p0 -i myfirstpatch.diff angewandt und committed werden. Der Befehl sollte im selben Ordner ausgeführt werden, in dem der Patch auch erstellt wurde (im SVN-Root). Der Parameter -p0 stellt sicher, dass alle Dateien gefunden werden. Mit -i wird die Patchdatei angegeben (kurz für input).

Unter Windows wird es einen ähnlichen Weg geben, dies konnte ich leider nicht testen.

Compared to modern languages like C# or Java, C++ lacks in support of dynamically loading code at runtime. It is not easy to implement a portable plugin-framework, but it is possible. Luckily there are frameworks available which make such a functionality possible.

Nokias QT-Framework is one of the most active and best maintained frameworks for C++. Besides the famous GUI-functionality are some neat features like reimplementations of the std-features Lists, Strings, Maps etc. It also has a plugin-framework integrated. For testing purposes, I wrote the MediaMasher plugin-architecture in C++ with QT-Plugins:

(click on image for resize)

The finished project is uploaded to a git-repository and could be downloaded HERE.

It includes a library which adopts the above UML-architecture. Additionally a binary using the lib with a hardcoded sample-source is included. The path points to a systemsound in Ubuntu 10.04. It could be easily changed in /test/TestMain/main.cpp

For building the project CMake is needed. It was another goal for me to demonstrate how QT and QPlugin could be included in such a build-environment.

Unfortunately there is not much documentation about QPluginLoader and the related mechanisms. Besides an official Plug and Paint example directly in the QT-documententation is just the class reference. There isn’t much info in blogs or by projects using this framework.

Finally I’ll show the POCO-Framework as an alternative to the QT-framework. The ClassLoader-component could be interesting for commercial projects which could not effort a QT developer licence (commercial licences start at 3000€ for QT)

Just ask if there are any questions about the example-code or if I should give some deeper explanation.

Um zu testen, ob die geschriebenen Unittests wirklich alle wichtigen Teile des Codes abdecken, führt man Coverage-Tests durch. Hierbei wird der Test ausgeführt und geloggt, welche Zeilen im Code angesprungen werden.

Im Bild ist ein Coverage-Report abgebildet, bei dem der if-Zweig des Programmes nicht berücksichtigt wird. Der zugehörige Unittest hat also nur einen Teil des Codes überprüft und sollte erweitert werden.

Doch womit generiert man Coverage Reports?

Unter Linux gibt es das Tool gcov, welches in Zusammenarbeit mit gcc textuelle Auswertungen erstellen kann.

 

Diese Reports sind leider nicht sehr informativ, sie lassen sich nicht besonders gut lesen und es fehlt eine Zusammenfassung der Coverage.

Abhilfe schafft hier das Tool lcov, welches bei vielen Distributionen in den Repositories liegt. Es verarbeitet die Coverage-Informationen des gcc zu einer info-Datei, die man dann mit dem zugehörigen Tool genhtml in einen HTML-Report konvertieren kann.

Der erste Screenshot dieses Artikels zeigt einen Teil des Beispielreports auf der lcov-Webpage. Auf dieser Seite befindet sich auch eine Anleitung für die Report-Generierung mit lcov.

Freitag erschien der dritte RC von KDevelop4. Bis zur finalen Veröffentlichung Anfang Mai ist es also nicht mehr lang hin.

Wer vorab schonmal einen Blick riskieren möchte, findet HIER eine Schritt für Schritt Anleitung zur Installation unter Linux. Wenn man zusätzlich noch die Requirements beachtet, klappt eigentlich alles ohne Probleme.

Ich habe den RC1 bereits auf der Arbeit kompiliert und im Einsatz. Die Daten, auf denen ich arbeite, sind natürlich alle soweit gesichert. Bisher gab es keine Probleme.

Im Vergleich zur Beta-Version sind allerdings einige Funktionen herausgefallen. So habe ich beispielsweise noch keine Möglichkeit gefunden, gcov einzusetzen. Da derzeit allerdings wöchentlich neue Versionen mit neuen Features erscheinen, werde ich zunächst auf die Release-Version warten.

Einige Funktionen lassen sich über Plugins nachrüsten. Hierfür gibt es ein Repository “extra-plugins”. Im KDevelop-Wiki befindet sich eine (veraltete?) Anleitung, wie man beispielsweise das PHP-Plugin bauen kann.

Nach dem ich HIER schon sehr zuversichtlich war, dass das Problem soweit gelöst ist, taten sich in den folgenden Wochen dieselben Probleme erneut auf. Nachdem der Netgear-Support schon soweit gegangen ist, ein komplettes Abbild meiner Router-Konfiguration anzufordern, konnte weiterhin keine Lösung erreicht werden.

Letzte Woche bekam ich dann abschließend eine Email, in der mir vorgeschlagen wurde, den kaputten Router einzuschicken. Nach dem Eintreffen bei Netgear würde mir umgehend ein Neugerät bereitgestellt werden. Das ich in dem Fall locker eine Woche ohne Netz wäre, schien dort niemanden zu stören.

Auch die zweite Lösung, bei der ich das Neugerät vor dem Verschicken meines kaputten Routers bekäme, war nicht wirklich zumutbar, hätte ich in dem Fall doch 30€ zusätzlich zahlen sollen. Vor dem Hintergrund, dass der Router an sich nur 40€ wert ist, ein lächerlicher Vorschlag.

Ich werde mir also selbst einen neuen Router zulegen (diesmal mit integriertem DSL-Modem). Den Netgear-Router kann man vielleicht irgendwann nochmal gebrauchen.

Mit dem D-Link DSL-2741 habe ich hoffentlich einen würdigen Ersatz gefunden. Alle von mir gesichteten Testberichte fielen unterm Strich positiv aus.